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Readers'  Guide 


This  section  contains  some  reader  hints  and  several  suggested  reader  road¬ 
maps. 

The  metrics  project  was  an  ambitious  project,  so  it  is  no  surprise  that  this  report 
is  an  ambitious  document.  There  is  more  than  one  idea  reported  here  for  the  first 
time,  more  than  a  few  controversial  issues  are  touched  upon,  many  disciplines  are 
invoked,  and  solutions  presented  depend  on  difficult  ideas. 

Early  in  the  project,  we  struggled  with  how  best  to  present  our  results.  Like  agil¬ 
ity,  the  insights  are  systemic,  they  may  be  interesting  individually,  but  they  gain 
greater  power  when  linked  together.  Our  problem  as  we  knew  it:  we  needed  to 
produce  one  document,  but  we  knew  we  had  widely  differing  purposes  and  several 
distinct  types  of  readership. 

So  what  weVe  done  is  create  a  hypertext  document.  Instead  of  just  being  a  dig¬ 
itized  report,  we  authored  it  to  take  advantage  of  the  hypertext  medium's  strength 
to  allow  a  reader  to  set  their  own  linear  path.  We  provide  several  aids  to  assist  that 
navigation: 

iMany  hyperlinks.  There  are  a  few  thousand  links  in  the  text.  Usually,  they  take 
the  reader  to  a  place  where  more  detail  on  the  topic  is  given.  We've  been  judi¬ 
cious  in  how  these  are  used  and  placed  them  only  where  we  think  the  user  will 
trigger  them.  For  example,  the  term  AVE  Focus  Group  is  used  and  tagged  fre¬ 
quently.  But  we  think  that  tagging  every  instance  is  distracting.  So  we  tag  it  when 
we  think  more  information  might  be  desired. 

^We've  made  each  narrative  self-contained  as  much  as  we  could.  This  has 
resulted  in  some  redundancy.  We  felt  that  readers  should  not  have  to  jump 
around  merely  to  follow  what's  going  on.  In  each  case,  there  is  one  detailed  dis¬ 
cussion  to  which  one  can  jump  from  the  watered  down  summaries  placed  in  cer¬ 
tain  discussions  in  order  to  preserve  the  flow. 

The  philosophy  of  self-contained  narratives  has  forced  us  away  from  using  acro¬ 
nyms  in  almost  all  cases  unless  defined  immediately  before.  This  is  a  boon  to  any 
reader  we  think.  The  only  exceptions  are  AVE  and  VE  which  are  so  common  that  if 
they  were  spelled  out,  the  long  form  would  be  distracting. 

^We've  provided  several  textual  aids: 

^An  annotated  Table  of  Content  which  will  probably  serve  as  the  basic 
map  for  most  readers. 

^A  good  Index  which  will  help  those  looking  for  coverage  of  specific 
topics. 

iAn  abstract  at  the  beginning  of  each  section  which  provides  a  hot-linked 
overview  of  that  part.  All  of  these  abstracts  are  reproduced  below. 

,  ^A  few  reader  guides,  later  on  in  this  preface.  These  are  provided  as  an 

overview  for  people  with  agendas  that  do  not  map  well  to  the  report's 
four  divisions.  We  give  an  example-based  roadmap  and  a  contract 
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reviewer's  roadmap. 

4V\fe  expect  to  have  four  specific  types  of  readers,  so  have  structured  the  report 
to  contain  four  main  parts.  These  sections  inter-relate: 

^Part  1:  This  is  for  someone  who  just  wants  the  useful  results  of  the 
project:  what  tools  resulted  and  how  do  they  work  (with  an  example).  The 
first  section  of  this  part  serves  as  a  self  contained  executive  summary  of 
the  metrics  only. 

^Part  2:  Some  critical  readers  will  want  to  know  the  underlying  definitions 
and  associated  issues  as  well  as  how  this  project  relates  to  others.  Part  2  is 
for  them. 

iPart  3:  A  major  result  of  the  project  has  bearing  above  and  beyond  the 
metrics:  how  to  rigorously  deal  with  social  and  cultural  issues.  This  major 
thread  deserved  its  own  part.  Many  examples  are  packed  into  this  thread. 
^Part  4:  One  goal  of  the  project  is  to  transfer  the  method  and  associated 
technology.  This  part  is  the  most  technical  of  the  four,  giving  those  details, 
which  also  includes  a  related  case  study. 

^  We've  studied  numerous  sites  and  have  concluded  that  the  best  browser  experi¬ 
ences  are  when  the  pages  load  fast,  fast,  fast.  So  we've  tailored  the  document  to 
have  small  sections.  Dependence  on  graphics  in  order  to  understand  the  point  is 
kept  to  a  minimum.  In  the  HTML  version  the  sections  are  small  and  the  graphics 
are  black  and  white  gifs  (except  for  screen  shots).  Nearly  everything  in  this  docu¬ 
ment  has  been  beta-tested  for  both  content  and  electronic  form',  this  is  several 
generations  advanced  from  our  early  format,  based  on  feedback  from  our  web 
site. 
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1  Reader  Guides 


1 . 1  Abstracts  of  Parts 

What  we  give  here  are  identical  copies  of  the  abstraas  contained  in  each  part 

1.1.1  Abstract  of  Part  1 

Part  1  is  for  readers  who  simply  want  a  users'  view  of  the  metrics  and  how  thev 
work.  ^ 

We  provide  an  executive  overview  of  the  metrics  with  an  example.  Details  on 
the  approach  are  given,  first  the  Reference  Model  which  is  central  to  the  first  step. 
In  describing  the  model,  we  review  some  case  studies  we  used  in  calibrating  the 
model  .  A  review  of  the  second  central  element  of  the  process,  communicative  act 
modeling  is  given  in  some  detail. 

Finally,  we  introduce  a  process  not  central  to  the  metrics,  concerned  with  stra¬ 
tegic  brainstorming  for  agility.  We  devised  this  method  because  apparentlv  none 
existed.  ^ 


1.1.2  Abstract  of  Part  2 

Part  2  is  targeted  toward  the  reader  who  is  interested  in  indcpth  discussion  of 
issues  which  surrounded  the  project. 

In  this  part  are  collected  a  number  of  results  on  which  were  incidentally 
reached.  There  are  a  few  examples  given:  agility  as  competitive  weapon,  and  ex¬ 
tremely  dynamic  market  forces.  The  benefits  to  the  U.  S.  economy  and  the  defense 
base  are  reviewed. 

Pr^’ects  which  lead  up  to  the  metrics  project  are  summarized,  as  well  as  techni- 
f/r  contributed  to  success  of  the  effort.  An  exhaustive  examination 

of  definitions  is  given:  The  virtual  enterprise,  the  agile  virtual  enterprise,  and  manv 
issues  related  to  metric. 

We  compare  agility  to  many  other  efforts  which  benefit  an  enterprise,  and  other 
sponsored  agility  research.  A  short  summary  of  the  approach  is  recounted  and 
known  limits  are  reviewed. 

1.1.3  Abstract  of  Part  3 

Part  3  is  for  the  reader  who  is  interested  in  social  and  cultural  issues  and  what 
weve  done  about  them.  Many  examples  are  in  this  part. 

We  begin  this  part  by  recounting  an  extensive  example  beginning  in  the  whaling 
industry  and  ending  with  agile  movie  production  processes.  We  continue  with  a 
specific  movie  case,  software  coding,  Russian  entrepreneurs,  and  virtual  car  man- 
^ufacturing. 

Cultural  agents  are  introduced,  and  some  background  issues  discussed  Trust 
trust  agents  and  trust  metrics  are  defined. 
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We  review  French  and  English  history  to  extract  key  insights  into  defense  engi¬ 
neering  practices.  Then  we  tie  it  back  to  the  movie  example  with  a  case  of  trusted 
agents  using  lightweight  contracts  and  unifying  themes.  And  the  whole  affair  is 
tied  back  to  the  defense  case.  The  case  for  defense  support  is  made. 

We  then  turn  to  the  specific  approaches  to  soft  mathematics.  Situation  theorv 
is  introduced  and  explained. 

We  report  on  our  activity  in  setting  up  a  workshop,  report  results  of  that  work¬ 
shop,  and  detail  future  action  we  plan. 

1.1.4  Abstract  of  Part  4 

Part  4  is  for  those  who  need  more  detail  about  the  defense  case  and  how  to  de¬ 
velop  tools.  It  is  a  little  more  technical. 

In  order  ^  set  the  stage  for  a  case  study,  a  specific  missile  problem  is  noted.  We 
note  the  difference  in  the  defense  legal  system  and  explain  it  historically.  Using 
these  insights,  an  ideal  defense  supply  chain  is  proposed. 

After  giving,  in  detail,  a  scenario  we  studied  then  set  aside,  we  set  up  the  case 
study  scenario.  The  questionnaire  we  used  is  reproduced.  Then  the  results  are  re¬ 
ported.  Within  the  case  study,  we  had  occasion  to  consider  how  we  would  work 

with  methods  of  consultants;  how  we  would  integrate  with  a  representative  svs- 
tem  is  reported. 

We  then  turn  to  tools  whose  need  was  indicated  in  the  study.  Several  tools  are 
described.  One  of  these  tools,  the  one  most  immediately  needed  has  been  proto- 
typed.  Its  internal  structure  is  given  in  detail.  That  tool  automates  an  algorithm 
which  IS  central  to  the  metrics.  The  algorithm  is  outlined  here. 

In  terms  of  future  tool  actions,  we  mention  our  own  special  strength  we  bring 
to  future  toolsets  and  outline  how  we  will  integrate  with  other  projects. 

1.2  For  the  Example-Oriented  Reader 

When  we  started  the  project,  we  made  a  deliberate  decision  to  be  rigorous  in 
our  work.  So  many  writings  from  others,  not  only  in  the  agility  space,  but  the 
whole  area  of  enterprise  technology  seemed  superficial.  A  characteristic  is  to  pro¬ 
vide  some  anecdote,  generalize  and  move  on.  In  eschewing  superficiality  we  de¬ 
cided  to  keep  this  report  empty  of  examples. 

We  were  quickly  disabused  of  that  notion.  Not  only  is  it  true  that  the  closest  way 
to  comprehension  is  through  example,  but  also  that  we  had  to  show  how  some  of 
our  notions  work  in  real  life.  Moreover,  as  the  work  progressed,  we  were  present¬ 
ed  with  such  interesting  stories,  such  compelling  cases  that  we  couldn't  contain 
ourselves. 

No  danger  of  that;  our  support  group  demanded  the  examples,  many  needing 
►them  to  support  just  the  same  rigorous  thinking  we  wanted.  A  note  about  our  ex¬ 
amples.  In  no  case  will  you  find  these  examples  anywhere  else  in  this  form.  These 
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are  not  remote  observations,  common  to  the  management  press;  each  case  was 
discovered  and  analyzed  specifically  for  the  project  and  this  report. 

Most  sources  are  proprietary,  which  is  a  nuisance  for  sure,  and  some  cases  are 
noted  as  an  anonymous  company.  But  our  experience  on  prior  projects  have  con¬ 
vinced  us  that  this  is  the  best  way  to  get  fresh,  real  information  out.  We  give  some 
public  sources  for  background  on  the  cases  in  the  bibliography,  for  those  who 
want  to  examine  them  more  closely. 

In  particular,  the  sweeping,  multidimensional  movieAvhaling/law  example  is 
based  on  heavily  proprietary  insights. 

1.2.1  Example  Reader's  Guide 

There  is  a  wideranging  case  study  which  appears  throughout  the  report.  It  cov¬ 
ers  a  couple  hundred  years,  ending  in  a  specific  defense  manufacturing  example, 
the  ideal  and  the  real  situation. 

It  begins  with  the  U.  S.  whaling  industry  as  an  example  of  a  virtual  enterprise, 
how  it  had  an  agile  response  to  the  gold  rush,  and  again  to  the  discovery  of  petro¬ 
leum.  We  track  how  much  of  the  cultural  and  legal  infrastructure  from  the  oil  in¬ 
dustry  was  inherited  from  the  whaling  industry  and  passed  to  the  movie  business. 

The  movie  business  is  examined  more  closely.  We  follow  how  its  cultural  and 
legal  infrastructures  were  used  as  an  example  by  the  Japanese  in  their  engineering 
of  enterprise  infrastructure  after  the  war.  Then  a  major  improvement,  the  packet 
unit  system  was  introduced  to  movie  production  by  wartime  research  sponsored 
by  the  predecessor  of  the  Air  Force  Manufacturing  Technology  Directorate,  moti¬ 
vated  by  success  in  the  Panama  Canal. 

This  flourished  and  became  the  focus  of  second-generation  attention  by  the  Jap¬ 
anese  as  a  model  for  more  agile  enterprise  engineering  technology.  The  center- 
piece  of  that,  the  use  of  high  concept  descriptors  to  supplement  agile  assembly  of 
virtual  enterprises  is  examined,  and  we  give  a  case  where  a  Japanese  firm  learned 
a  hard  lesson. 

We  look  at  how  an  ideal  defense  aerospace  supply  chain  would  look  if  it  fol¬ 
lowed  these  principles,  and  assume  that  to  be  a  strategy  for  a  typical  missile  prime. 
We  further  assume  that  the  missile  prime  is  addressing  a  very  real  defense  vulner¬ 
ability  which  likely  will  result  in  combat  losses,  not  because  of  a  lack  of  funding  or 
technology,  but  because  the  supplier  base  is  unagile. 

We  look  closely  at  a  real  defense  prime  to  see  how  much  it  would  cost  to  collect 
the  information  required  to  use  the  metrics  to  reengineer  the  supply  chain  with 
the  ideal  in  mind,  and  find  the  cost  in  line  with  reengineering  of  similar  ambition. 
A  subset  of  that  example  is  used  to  illustrate  the  executive  summary.  Along  the 
way,  we  look  at  a  representative  reengineering  methodology  to  check  how  easily 
the  metrics  can  be  integrated.  (Elsewhere,  we  do  the  same  for  integrating  the  met¬ 
rics  into  other  sponsored  agility  projects.) 

Incidentally,  we  examine  other  examples: 

^A  railroad  which  has  a  novel  strategy  of  creating  virtual  enterprises  to  develop 
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its  customer  base. 

dA  bidding  consortium  which  represent  many  small  firms  as  if  they  were  one. 

^An  aerospace  prime  who  invests  in  codifying  knowledge  for  transfer  to  partners 
of  convenience. 

consumer  electronics  prime  which  has  an  innovative  way  of  evaluating  the 
possible  liabilities  carried  by  potential  suppliers. 

^A  defense  electronics  prime  which  engages  suppliers  in  strategic  new  product 
definition. 

^An  airline  that  invests  a  supplier  with  highly  proprietary  knowledge  though  that 
supplier  is  tightly  coupled  to  the  airline's  competitors. 

^A  shipyard  that  engages  its  defense  suppliers  to  manufacture  a  commercial  pro¬ 
cess  plan  as  if  it  were  a  physical  product. 

^A  software  house,  itself  a  virtual  enterprise,  which  uses  a  novel  risk  reward 
strategy  to  produce  companywide  agility. 

^A  revisiting  of  many  of  the  above  two  years  later  to  show  how  agility  they  had 
failed  to  help  when  the  agility  need  was  unplanned  for. 

^How  the  workprocessing  business  changed  hands. 

^How  the  electronic  game  device  business  changed  hands. 

^How  control  over  broadcast  electronics  changed  hands. 

^Where  agility  was  used  as  competitive  weapon  in  the  automotive  industry. 

^Where  agility  was  similarly,  and  more  massively,  employed  as  a  weapon  in  the 
fast  food  business, 

^Where  Israeli  defense  acquisition  planners  used  agility  to  address  a  missile 
threat. 

^Where  earlier,  Soviet  launch  vehicle  managers  did  the  same  thing,  and  how  the 
technique  has  penetrated  the  new  Russian  entrepreneurs. 

^Why  agility  is  found  in  Indian  software  collectives  as  a  cultural  effect, 

iWhy  a  major  automotive  virtual  enterprise  in  the  U.  S.  failed  for  cultural  rea¬ 
sons. 


^Why  a  major  semiconductor  virtual  enterprise  in  the  U.  S.  failed  for  different 
cultural  reasons. 

^What  benefits  certain  behind  the  scenes  associations  see  in  agility. 

^What  benefits  the  investment  community  sees  in  agility. 

^How  trust  is  culturally  based. 

We  hope  you  enjoy  these  examples.  None  of  them  were  developed  as  much  as 
we  would  like,  or  even  described  here  as  much  as  they  were  developed.  If  we  had, 
their  role  in  supporting  and  illustrating  the  novel  contribution  to  metrics  would 
have  been  compromised. 
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1 .3  For  the  Contract  Reader 

This  report  is  the  product  of  work  sponsored  by  the  U.  S.  Department  of  De¬ 
fense.  The  funder  is  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  and 
the  manager  is  the  Manufacturing  Technology  Directorate  of  the  Air  Force  Wright 
Laboratories  (ManTech).  The  overall  program  of  which  this  is  a  part  is  the  DARPA/ 
NSF  Agile  Manufacturing  Program,  which  involves  many  sponsored  efforts.  The 
contact  number  is  F33615-95-C-5513,  being  a  successful  response  to  Broad  Area 
Announcement  94-31 . 

The  contract  requires  a  specific  structure  for  a  final  report  (CDRL  AOOl ),  which 
is  addressed  in  this  section. 

1.3.1  The  Problem  Addressed  During  this  Effort 

Agility  is  a  new  concept  which,  because  it  is  new,  is  difficult  to  grasp,  albeit  easy 
to  define.  As  a  result,  many  researchers  have  fallen  back  on  older  concepts,  and 
existing  tools  under  the  rubric  of  Ag/7/fy.  In  any  case,  the  majority  of  work  has  been 
either: 

ia  revisiting  of  existing  tools  and  technologies  under  the  belief  that  if  they  were 
only  done  better,  agility  would  result  or  be  improved 

consolidating  of  thoughts  into  very  high  level  guidelines,  themes  and  rules  of 
thumb  that  are  speculated  to  support  one  of  the  definitions  of  agility.  Generally, 
these  guidelines  are  used  for  motivational  purposes. 

While  these  efforts  may  be  useful,  they  still  do  not  satisfy  the  key  questions  that 
must  be  addressed  in  order  for  managers  to  be  able  to  engineer  the  ability  to  re¬ 
spond  to  change  into  a  diversified  enterprise. 

We  need  to  know  how  to  evaluate  the  threat,  how  to  determine  whether  pro¬ 
cess  or  partner  is  agile,  whether  it  is  sufficiently  so  (to  address  the  threat)  and  what 
the  relative  costs  will  be.  We  need  quantitative,  objective  metrics  that  speak  di¬ 
rectly  to  an  engineering  analysis  of  the  enterprise.  We  need  a  foundation  for  bal¬ 
ancing  the  costs  of  agility  against  its  benefits. 

The  Defense  Industrial  Base  is  clearly  in  need  of  re-engineering.  Some  of  the 
problems,  including  a  major  one  we've  identified,  are  a  result  of  a  non-agile  sup¬ 
plier  base.  If  agility  is  to  be  engineered  into  a  supplier  base  for  a  weapon  system 
or  class  of  weapon  systems,  then  engineering  tools  need  to  be  developed,  and 
metrics  are  the  first  step  on  such  development. 

We  know  that  such  engineering  tools  will  not  flourish  In  the  defense  base  unless 
they  are  enthusiastically  supported  in  the  civil  sector.  We  also  believe  that  rigor¬ 
ous  foundations  are  essential,  but  integration  with  many  intuitive  tools  and  meth¬ 
ods  must  be  effected  in  order  for  the  metrics  to  be  useful. 

So  we  addressed  the  creation  of  formal  metrics  for  pure  agility  that  can  be  used 
»by  civil  and  defense  sectors,  and  easily  integrated  into  many  tools  and  methods  for 
diverse  users.  We  used  the  Defense  Agile  Virtual  Manufacturing  Enterprise  as  the 
most  difficult  case. 
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1 .3.2  The  Work  Performed  Under  this  Effort 

We  knew  that  the  project  was  ambitious:  we  had  been  the  government's  agent 
on  a  multibillion  dollar  attempt  at  the  same  target  which  had  failed.  But  we  be¬ 
lieved  that  we  could  align  a  number  of  parallel  trends,  prior  results,  and  new  play¬ 
ers  to  quickly  synthesize  some  high  value  results. 

4We  devised  formally-based  agility  metrics  that  can  be  inserted  into,  interfaced 
to,  integrated  within  or  accessed  by  a  wide  number  of  important  tools  and  meth¬ 
ods  by  a  spectrum  of  users. 

4\Ne  mobilized  a  review  panel  that  involved  over  a  hundred  persons  which  met 
dozens  of  times.  We  conducted  a  wider  review  by  a  dedicated  email  list,  and  a 
web  site  which  involved  thousands  of  interactions. 

4We  conducted  a  sweeping  case  study  that  followed  the  evolution  of  legal  infra¬ 
structure  resulting  in  a  defense  base  problem.  This  large  effort,  which  involved 
the  movie  business,  was  partially  subsidized  by  a  large  consulting  firm.  This  case 
study  evolved  into  a  close  look  at  a  specific  coupling  of  an  example  consulting 
group  and  a  defense  aerospace  prime  to  determine  the  cost  of  applying  the  met¬ 
rics.  While  costly,  the  process  compares  to  similar  strategic  modeling  tasks.  The 
first  chapter  of  the  case  study  was  published  by  the  Agility  Forum  and  as  been 
widely  quoted  in  business  media. 

4We  conducted  a  dozen  individual  case  studies  to  develop  and  validated  the  AVE 
Reference  Model. 

4We  spun  off  an  independent  activity  to  address  advanced  soft  issues,  primarily 
the  engineering  of  social  and  cultural  dynamics.  This  spinoff  was  cofunded  with 
industry  and  has  set  the  foundation  for  promising,  perhaps  revolutionary  work 
that  has  already  resulted  in  two  books  1DEVL97]  1DR96]. 

^We  clearly  and  publicly  described  the  key  algorithm  and  object  implementation 
strategy  so  that  tool  suppliers  could  see  what  is  going  on  and  tool  builders  can 
evaluate  instancing  the  metrics.  We've  also  outlined  examples,  and  in  some  cases 
prototyped  tools  that  would  employ  the  metrics.  These  are  downloadable  from 
the  web  site. 

i  We've  been  remarkably  successful  in  communicating  the  results  through  the 
physical  and  virtual  meetings  noted  above.  These  have  been  supplemented  by 
dozens  of  private  presentations  to  commercial  sites,  and  numerous  professional 
conferences. 

1 .3.3  Relevant  Test  Results 

We  supported  two  different  types  of  tests: 

^Continuous  testing  of  the  ideas  in  the  project  by  AVE  Focus  Group  (and  its  elec¬ 
tronic  siblings)  by  close  examination  of  a  dozen  or  so  case  studies. 

)  4A  single,  focused  instance  of  a  missile  prime  and  a  (for  our  purposes)  represen¬ 
tative  consultant,  which  formed  part  of  our  major  multi-industry  case  study.  The 
purpose  was  to  determine  whether  the  cost  of  modeling  for  strategic  agility  was 
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greater  than  similar  modeling  to  support  strategic  planning. 

1 .3.4  Program  Benefits 

We  believe  that  we  now  have  workable  metrics  and  a  tool  strategy  that  can  be 
used  to  engineer  agile  supply  chains  in  specific  industries  where  the  changerate  is 
high.  These  can  be  applied  in  a  future  phase  on  emerging  defense  aerospace  sys¬ 
tems. 

1.3.5  Implementation  Benefits 

1.3. 5.1  Generalizations 

We  have  presented  the  statement  of  the  problem  and  the  solution  in  a  variety  of 
ways  for  different  constituencies.  We  have  identified  four  major  groups  which  cor¬ 
respond  to  the  four  sections  of  this  document.  All  indications  are  that  we  have  suc¬ 
ceeded  in  our  goal  of  speaking  to  tool  builders  and  strategic  planners  in  both  the 
civil  and  defense  sectors. 

But  there  is  a  group  that  will  be  outside  our  reach.  We  have  determined  that 
there  are  large  segments  of  the  economy  for  whom  agility  is  neither  a  concern  nor 
should  it  be  (A),  and  this  includes  important  parts  of  the  defense  industrial  base. 
However,  electronics  and  aerospace  systems,  especially  complex  systems  are  likely 
candidates  for  agility. 

1.3. 5. 2  Implementation  Schedule 

We  plan  to  follow  through  in  making  the  metrics  widespread.  Some  methods 
and  strategies  will  be  given  away,  others  licensed.  We  also  plan  to  bring  to  prod¬ 
ucts,  the  tools  outlined  in  Part  4. 

1 .3.5.3  The  Contractor's  Toolbox 

Our  statement  of  work  doesn't  call  for  a  specific  implementation.  But  we've  ac¬ 
celerated  an  implementation  strategy  beyond  what  we  planned.  Although  the  ef¬ 
fort  was  unrealistically  ambitious,  we  were  able  to  leverage  other  efforts  and 
obtain  industry  cofunding.  So  we  were  able  to  prototype  our  primary  suggested 
tool  instead  of  merely  specifying  it. 

1 .3.5.4  Target  Industries 

It  is  clear  from  our  industry  advisors  that  only  large  primes  have  the  luxury  of 
engineering  supply  chains,  and  this  is  true  of  engineering  agility  as  well.  We  have 
>also  found  that  only  a  portion  of  industry  will  be  concerned  with  agility  because 
their  changerate  is  low. 
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Clearly  aircraft  and  missile  projects  are  targets  for  the  results  of  this  research, 
and  we  expect  to  pursue  solving  some  problems  in  this  sector. 

As  noted  in  Part  2,  non-U.  S.  firms,  especially  in  emerging  economies  are  very 
interested  in  both  agility  and  the  metrics.  This  appears  to  be  because  they  have 
less  legacy  that  is  immutable.  They  are  building  whole  new  industries  from  scratch. 
For  instance,  we  were  visited  by  a  Chinese  delegation  chartered  with  establishing 
a  major  domestic  aircraft  industry,  and  they  wanted  to  be  more  agile  than  Boeing 
and  AirBus. 

1 .3.5.5  Relevant  Conferences 

We  have  found  that  the  web  site  is  the  most  powerful  way  of  publishing.  It  gets 
an  average  of  4,000  hits  a  month.  We  expect  that  to  greatly  increase  as  new  mate¬ 
rial  appears.  We've  described  in  some  detail  communities  which  we've  leveraged, 
and  how  we'll  continue  to  leverage  them. 

We've  published  the  first  part  of  the  case  study  as  a  report  by  the  Agility  Forum, 
and  will  have  the  executive  summary  of  Part  1  published  in  Agility  and  Global  Com¬ 
petition.  We've  been  asked  to  write  our  results  in  the  new  Springer  Verlag  Inter¬ 
national  Handbook  on  Information  Systems,  and  have  an  article  in  the  forthcoming 
BioSystems. 

The  metrics  have  become  involved  in  the  Series  of  meetings  by  the  Foundations 
of  Information  Science,  the  International  Society  for  the  Interdisciplinary  Study  of 
Symmetry,  and  the  International  Society  for  Group  Theoretic  Cognitive  Represen¬ 
tation  and  International  Conference  on  Enterprise  Integration  Modeling  Technol¬ 
ogy. 

We've  presented  in  three  Agility  Conferences,  three  BAST  Conferences,  the  Na¬ 
tional  Virtual  Corporation  Conference  and  the  National  Business  Process  Re-engi¬ 
neering  Conference  in  addition  to  meetings  of  the  societies  noted  above.  These 
have  been  useful,  but  we  think  that  the  most  powerful  strategy  is  web  publication 
balanced  with  concentrated  site  visits. 

1 .3.6  Summary 

We  realized  that  the  agenda  was  ambitious  and  could  only  be  addressed  by  the 
effort  of  a  large  coordinated  interdisciplinary  group.  So  that  is  the  approach  we 
took.  We  spend  substantial  effort  in  facilitating  multiple  parallel  focused  efforts. 
Some  of  these  were  electronically  based. 

By  these,  and  a  few  special  subprojects  funded  or  cofunded  by  others,  we  were 
successful  in  leveraging  the  government's  investment  manifold. 

In  terms  of  results,  we  have  achieved  the  definition  and  validation  of  formally 
based  quantitative  metrics  to  evaluate  engineering.  We've  described,  and  posted 
^on  the  web,  several  ways  that  these  metrics  can  be  used  in  different  methods,  tools 
and  research  thrusts. 
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We  also  have  produced  two  unexpected  products  which  have  assumed  high  im¬ 
portance.  With  Sandia,  Automation  and  Robotics  Research  Institute  and  the  AVE 
Focus  Group,  we  have  developed  a  structured  controversy  method  for  brainstorm¬ 
ing  agile  strategies  and  alternatives. 

Also  we  have  instigated  with  Steelcase,  Automation  and  Robotics  Research  In¬ 
stitute  and  Industrial  Technology  Institute  a  major  effort  In  Soft  Modeling:  a  new 
approach  to  modeling  the  unknown  and  social/cultural  dynamics. 
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who  and  how  are  given.] 
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(Components  in  the  model  dealing  with  how  a  prospective  Agile  Virtual  Enterprise 
identifies  whether  an  opportunity  exists  and  what  its  nature  is.) 
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4. 2.3.3  Enterprise  Metrics . 64 

4. 2. 3.4  Capitalization . 64  , 
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4.2.3.6  Risk/Reward  Strategies . 65 

4. 2.3.7  Operating  Structure . 65 

4. 2.3. 8  Dissolution  Plan . 66 

4.2.4  Process  Category  4:  Operation . 66 

(The  model  supports  processes  involved  in  operating  the  virtual  enterprise.] 

4.2.4. 1  Performance  Measures . 67 

4. 2.4. 2  Customer  Relations . 67 

4. 2.4.3  Operating  Practice . 67 

4.2.5  Process  Category  5:  Reconfiguration  and  Dissolution . 68 


(The  model  supports  processes  associated  with  the  end  of  the  virtual  enterprise  and 


its  possible  recycling.) 
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here.) 
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discussion  on  how  they  can  to  be  named,  noting  alternatives,  and  internal  depen* 

dencies  among  them.) 


4.2.7. 1  Numbering . 75 

4.2. 7. 2  Naming . 77 

4.2. 7.3  Dependencies . 79 

4.2.8  Example  Cells . 80 


(The  Reference  Model  is  further  clarified  by  giving  detailed  examples  of  twenty  cells. 

Each  example  has  three  example  instances.) 

4.2.8. 1  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column 

C.a.e:  Legal/Explicit  Infrastructure:  Business  Processes:  Depth  of  Customer 
Relations . 81 

4. 2. 8. 2  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column 

C.b.b:  Legal/Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Con¬ 
tracts  . 82 

4. 2. 8. 3  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column 

C. c.c:  Legal/Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Break¬ 
down  Structure . 82 

4.2. 8.4  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column 

D. a.a:  Physical  Infrastructure:  Warehousing/Logistics:  Human  Collabora¬ 
tion  . 82 

4. 2. 8. 5  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  C.a.e:  Le¬ 

gal/Explicit  Infrastructure:  Business  Processes:  Depth  of  Customer  Rela¬ 
tions  . 83 

4. 2. 8. 6  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  C.b.b:  Le- 

gal/Expiicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Contracts83 

4. 2. 8. 7  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  C.c.c:  Legal/ 

Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown  Struc¬ 
ture . 84 

4.2. 8.8  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  D.a.a:  Phys¬ 
ical  Infrastructure:  Warehousing/Logistics:  Human  Collaboration84 

4.2. 8.9  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column  C.a.e: 

Legal/Explicit  Infrastructure:  Business  Processes:  Depth  of  Customer  Rela¬ 
tions  . 84 

4.2.8.10  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column 

C. b.b:  Legal/Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Con¬ 
tracts  . 85 

4.2.8. 1 1  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column  C.c.c: 

Legal/Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown 
Structure . 85 

4.2.8.12  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column 

D. a.a:  Physical  Infrastructure:  Warehousing/Logistics:  Human  Collabora¬ 
tion . 85 

4.2.8.13  Row4.1:  VE  Operation:  Performance  Metrics  and  Column  C.a.e: 

Legal/Explicit  Infrastructure:  Business  Processes:  Depth  of  Customer  Rela¬ 
tions  . 85 

4.2.8.14  Row4.1:  VE  Operation:  Performance  Metrics  and  Column  C.b.b: 
Legal/Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Contracts86 
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4.2.8.15  Row  4.1;  VE  Operation:  Performance  Metrics  and  Column  C.c.c: 

Legal/Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown 
Structure . 86 

4.2.8.16  Row  4.1:  VE  Operation:  Performance  Metrics  and  Column  D.a.a: 
Physical  Infrastructure:  Warehousing/Logistics:  Human  CoIlaboration86 

4.2.8.17  Row  5.1:  VE  Reconfiguration/Dissolution:  Identify  Need  for 

Change  and  Column  C.a.e:  Legal/Explicit  Infrastructure:  Business  Process¬ 
es:  Depth  of  Customer  Relations . 87 
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ness  Plan):  Work  Breakdown  Structure . 87 
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Human  Collaboration . 88 

4.3  Best  Agile  Practice  Examples . 88 

[The  Reference  Model  was  generated  in  the  context  of  a  significant  number  of  case  stud¬ 
ies.  Eight  examples  are  given  here.] 

4.3.1  Anonymous  Railroad . 89 

|A  railroad  forms  virtual  enterprises  on  behalf  of  future  freight  users.  How  they  iden¬ 
tify  opportunities  is  novel.) 

4.3.2  FlexCell . 91 


(A  successful  bidding  coalition.) 

4.3.3  Sikorsky . 91 
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(Partners  are  evaluated  in  part  on  the  potential  for  differing  types  of  liabilities.) 

4.3.5  Westinghouse . 95 

(Partners  drive  a  part  of  the  opportunity  identification  when  is  determined  by  emerg¬ 
ing  processes.) 

4.3.6  Anonymous  Airline . 96 

|A  novel  way  of  fencing  off  a  partner's  relationships  with  competitors  for  a  special 

project.) 

4.3.7  Anonymous  Shipyard . 97 

(A  process  plan  for  a  new  business  area  is  manufactured  as  if  it  were  a  product  of  the 

old  process  plan.) 

4.3.8  Taligent . . . 99 

(Risk  and  Reward  strategies  make  a  software  developer  change  a  few  times  in  mid¬ 
stream.) 

4.3.9  Recent  Events . 100 

(Events  since  the  case  studies  underscore  the  fact  that  agility  in  one  dimension  is  no 

guarantee  in  another.  A  surprising  number  of  the  example  best  practices  have 

failed.] 

5  Modeling  by  Communicative  Acts . 101 

(The  metrics  depend  on  breaking  Reference  Model  entries  down  further  into  communicative 
acts.  An  introduction  to  communicative  acts  is  given  in  this  section.) 

5.1  The  Emergent  Systems  Influence . . 101 
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|One  reason  for  communicative  arts  is  to  exploit  emergent  behavior,  such  as  that  exploit¬ 
ed  by  simulations,  or  as  appears  with  autonomous  agents.) 

5.2  The  Need  for  Federatable  Executables . 102 

[We  think  that  the  approach  could  in  the  future  support  self-organizing  enterprise  inte¬ 
gration  strategies.) 

5.3  IVIultiple  Representations . 102 

(Even  within  the  metrics  approach,  we  support  a  version  of  self-organizing  integration 

through  federation  of  our  own  internal  models.) 

5.4  Formal  Foundations . 104 


jCommunicative  acts  helps  us  lay  a  rigorous  foundation.) 

5.4.1  The  Conversation  Metaphor . 104 

IThe  approach  allows  us  to  see  processes  in  terms  of  conversations  of  communica¬ 
tive  acts.) 

5.5  Baclcground  of  Speech  Acts . 105 

jA  few  words  on  some  background  and  related  definitions.) 

5.5.1  Relevance  to  Agility . 106 

|A  small  seaion  on  communication  as  the  dynamic  coupling  which  some  define  as 

agility.) 

5.6  A  Candidate  Dynamics  of  Speech  Acts . 106 

|The  essentials  of  speech  acts  are  given  here.) 

5.6.1  Speech  Acts . 107 

[The  specific  types,  performatives,  of  speech  (communicative)  acts  are  defined.) 

5.6.2  Sequential  Relations . 108 


(The  rules  for  combining  acts.  These  are  used  later  in  calculating  the  Dooley  Graph.) 


5.6.2. 1  Respond . 108 

5.6.2.2  Reply . 109 

5. 6. 2.3  Resolve . 109 

5. 6. 2.4  Complete . 110 

5.6.3  An  Example . 110 


(An  example  of  a  process  to  speech  act  model  is  given.  The  Dooley  Graph  is  intro¬ 
duced.) 


6  Agile  Strategic  Planning . 115 

|The  metrics'  approach  assumes  a  strategy  exists.  Since  there  are  no  known  tools  for  agility 
planning,  we  created  one  as  a  side  project.  It  is  described  here.) 

6.1  Memes . 115 


|The  brainstorming  method  depends  on  harnessing  irrepressible  trends  in  groups.  A 
handy  way  to  describe  these  trends  is  as  memes.  So  a  brief  introduction  to  memes  is  giv¬ 
en.) 

6.2  Relevance  to  Brainstorming . 117 

(Why  memes  may  be  helpful  in  predicting  enterprise  agility.) 

6.3  Basic  Underlying  Principles/Controversies . 118 

(We  describe  a  specific  taxonomy  of  memes  that  can  be  leveraged  for  agility  brainstorm- 

ing.) 

6.3.1  Realism  versus  Phenomenalism . 120 

(Whether  one  believes  in  a  universal  clockmaker  of  some  kind  or  whether  the  clock 

invents  itself.) 

6.3.2  Intrinsic  versus  Random  Order . 120 

(Whether  the  behavior  of  the  clock  is  a  result  of  design  (extrinsic  or  intrinsic),  or  an 

accident  of  nature.) 

6.3.3  Evolution  versus  Revolution . 121 
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[Whether  new  clocks  emerge  incrementally  or  in  major,  disruptive  spurts.) 

6.3.4  Centralized  versus  Distributed  Control . 122 

[Whether  someone  central  determines  the  hour,  or  we  reach  it  by  consensus.) 

6.4  Role  Playing . 122 

[How  to  employ  the  controversies  described  above  in  a  structured  role  playing  context.) 

6.4.1  Future  Work:  the  Dooley  Graph  Link . 124 

[Still  to  be  done  is  mapping  this  method  at  a  finer  level  of  granularity  so  that  the  role 
playing  can  be  simulated  by  agents.) 

Part  2,  Issues  126 


Part  2  is  targeted  toward  the  reader  who  is  interested  in  indepth  discussion  of  issues  which  sur¬ 
rounded  the  projea. 


7  Abstract . 126 

8  Agility  is  Different . 127 


[A  case  is  made  that  agility  is  both  important  and  fundamentally  different  than  other  manage¬ 
ment  concerns.  Examples  are  given  where  agility  (or  lack  of  it)  is  a  faaor.  There’s  an  example 
of  an  instance  where  lean  is  not  agile.  We  outline  steps  for  agility  thinking.) 


8.1  Burger  Wars . 131 

[An  example  where  agility  is  used  as  a  competitive  weapon.) 

8.2  Competitive  Games . 133 

[An  example  sector  where  market  share  is  highly  dynamic.) 

9  Government  Sponsorship . 134 

[This  section  outlines  the  sponsors  of  the  project  and  provides  a  rationale  for  them  to  lead 

agility  research.) 

9.1  What  is  the  Domestic  Advantage? . 134 

[Results  of  studies  on  agility  benefits  to  the  economy.) 


9.1.1  U.  S.  Enterprises  Benefit  Relative  to  International  Competitors! 34 

[Agility  leverages  U.  S.  strengths  in  innovative  small  businesses  and  case  law.) 

9.1.2  U.  S.  Benefits  as  Suppliers  ofVE  Infrastructure  Produas  . . .  135 

[The  U.  S.  is  likely  to  provide  the  majority  of  the  agile-sensitive  information  infra- 

struaure  of  the  world.) 

9.1.3  U.  S.  Benefits  as  Suppliers  ofVE  Infrastructure  Processes  . .  136 

[The  U.  S.  is  likely  to  supply  a  high  percentage  of  innovative  process  technology  into 

a  world  of  agile  enterprises.) 

9.1.4  User  Firms  Can  Leverage  the  AVE . 137 

(Agile  enterprises  are  more  likely  to  do  well  in  other  desirable  traits,  such  as  quality 

and  productivity.) 

9.1 .5  New  Entrants  into  the  Market  will  be  Possible . 137 

|lt  will  be  easier  for  innovative  startups  to  thrive,  another  U.  S.  strength.) 

9.2  What  is  the  Defense  Advantage? . 138 

[Results  of  studies  concerning  benefit  to  U.  S.  defense.  Defense  industries  cannot  be  agile 
unless  commercial  tools  exist.  If  so,  civil  suppliers  can  be  shifted  in  and  out  in  both  peace 
giving  lower  costs  and  mobilized  for  emergencies,  providing  a  lower  cost  for  readiness.) 

10  The  Legacy  of  this  Approach . 139 

[Prior  work  gave  the  project  a  running  start.  It  is  desaibed  here.) 

10.1  Preceding  Work . 139 

[How  a  specific  thread  lead  to  the  project.  Includes  a  S40M  private  study.) 

,  10.2  Parallel  Trends  in  Theory . 140 

[Several  scientific  trends  provided  low  cost  leverage  by  having  ready  answers  when  need¬ 
ed.) 

10.2.1  Linguistic/Syntactic/Situation  Theories . 140 
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(Recent  trends  in  Situation  Theory  were  helpful.) 

10.2.2  Category  Versus  Set  Theories . 141 

(Work  in  the  structure  of  transforming  actions  provided  some  of  the  foundation.) 

10.2.3  Group/Graph  Theories . 142 

(Group  theories  provide  an  expected  boost  in  support  tools  for  analysis  in  a  second 

generation.) 

10.2.4  Component  Integration . 142 

(We  leveraged  emerging  trends  in  infrastruaure  which  will  result  in  a  new  genera¬ 
tion  of  tools  regardless  of  agility.) 

10.3  What  We've  Done . 143 

[Some  involvements  we  have  to  ensure  visibility  into  these  trends.[ 

11  Definitions . 

(Key  definitions  of  the  project.) 

11.1  . . . . 

(Definitions  related  to  the  virtual  enterprise.) 

11.1.1  Enterprise  Versus  Corporation . 145 

(Why  virtual,  why  enterprise.) 

1 1.1.2  Four  Types  of  VEs . ....145 

(We  allow  a  wide  variety  of  things  to  be  called  virtual  enterprises,  but  impose  a  basic 

taxonomy  on  the  major  types.) 

11.2  AVE . 

(Definitions  related  to  agility.) 

11.2.1  Definition  of  Agility . 147 

(Agility  deals  with  change.) 

1 1 .2.2  Agility  as  Creativity . 148 

(An  agile  organization  is  a  creative,  learning  one.) 

1 1 .2.3  Types  of  Agility . 149 

(Considerations  of  who  is  agile,  and  who  benefits.) 

1 1 .2.4  Other  Agility  Definitions . 150 

(Our  definition  is  exclusive  to  change,  but  others  use  the  term  more  broadly.) 

1 1 .2.5  Role  of  the  Organizer . 152 

(One  partner  is  an  organizer,  who  has  additional  agility  concerns,  how  agily  it  can 

organize  or  coordinate  organization.) 

1 1 .2.6  Types  of  Change . . . 153 

(Different  changes  require  different  types  of  agility.) 

12  Metrics . 

(Considerations  relating  to  what  the  metrics  themselves  are.) 

12.1  What  Are  We  Measuring? . .  155 

(We  don't  measure  what  you  did.  but  what  you  are  (likely)  capable  of  doing.) 

12.2  Upstream  Metrics . . . . 1 

(We  measure  in  a  fashion  that  can  indicate  what  needs  to  be  done  to  improve  agility.) 

12.3  Necessary  Conditions . . .  156 

(We  do  not  assume  that  there  are  any  agility  strategies  that  fit  all  conditions.) 

12.4  Dynamism  of  Metrics . ‘ 

(These  metrics  are  hard  because  they  measure  the  control  over  dynamic  coupling.  Agility 

is  like  insurance.) 

12.5  Difficulty  of  Benchmarking . 157 

(The  metrics  bear  no  relation  to  benchmarking  measures.  Agility  may  not  be  benchmark- 

able.) 

12.6  Two-part  Metrics . 
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|Each  response  has  to  take  into  consideration  the  nature  of  the  change  to  which  it  is  re¬ 


sponding.) 

12.7  Quantitatively  Scalable . 159 

(To  be  useful,  the  metrics  need  to  be  numbers  calculated  from  the  process,  not  subjec¬ 
tively  determined.) 

1 2.8  Legacy  vs.  Heritage . 162 

|An  optimal  agile  response  not  only  accomplishes  the  change,  but  does  so  in  a  way  that 

increases  your  agility  for  the  next  time,  probably  different.) 

12.9  Environmental  Drivers . 162 

|There  likely  are  some  external  conditions  within  which  enterprises  and  partners  exist 

that  will  tend  to  make  them  more  agile  than  without  those  conditions.) 

12.10  Strategic  Links . 163 

|The  metrics  need  to  support  the  differing  parameters  used  in  strategic  planning.  Those 

are  noted.) 

12.11  Rules  of  Thumb . 164 

)Repeated  use  of  the  metrics  will  result  in  some  rules  of  thumb  that  won't  need  the  ex¬ 
pense  of  calculating  numbers.) 

13  Agility  and  Other  Approaches . 166 

(There  are  other  beneficial  trends  underway.  How  does  agility  relate  to  them?) 

13.1  Agility  Forum  and  A^  Agility . 166 

(Our  work  complements  that  of  the  Forum  without  much  overlap.) 

13.2  Older  Agility  Forum  Work . 171 

|Our  work  also  complements  a  separate,  earlier  thread  of  the  Forum's,  with  a  little  more 

overlap.) 

13.3  Virtual  Manufacturing . 173 

|We  particularly  support  simulated  AVEs!) 

13.4  Activity-Based  Costing . 173 

(Activity  Based  Costing  is  irrelevant  to  agility.) 

13.5  Lean  Manufacturing . 175 

(Lean  and  agile  manufacturing  are  siblings,  but  being  one  doesn't  necessarily  result  in  the 

other.) 

13.6  Flexible  Manufacturing . 176 

IFlexible  manufacturing  is  an  (uninteresting)  special  case  of  agility.) 

13.7  Electronic  Commerce . . 177 

(Electronic  Commerce  and  agility  are  largely  unrelated.) 

13.8  Product  Data,  NlllP . 177 


(Agility  depends  on  process  coordination  in  a  way  not  affected  by  the  benefits  of  im¬ 
proved  product  data  exchange.) 

13.9  Enterprise  Integration . 178 

(Conventional  integration  strategies  depend  on  stability,  not  temporal  dynamism.) 

14  The  Agile  Manufacturing  Research  Program . 180 

(The  39  sponsored  agility  programs  are  related  to  the  Reference  Model.) 

15  Summary  of  the  Method . 184 

(Given  the  above  constraints,  a  short  statement  of  the  approach  is  given.) 

1 6  Limits  of  Our  Approach . 186 

(The  approach  has  limits.  Here  they  are.) 


16.1  Modeling  for  Utility . 186 

(The  modeling  approach  is  geared  to  producing  the  numbers  as  the  useful  result.  The  in¬ 
terim  models  are  not  generally  useful.) 

16.2  Necessity  for  Strategic  Modeling . 186 
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|No  strategy,  no  metrics.  A  surprising  number  of  enterprises  have  no  clear  strategy.  Strat¬ 
egies  are  expensive.] 

16.3  Second-Order  Agility . 187 

(This  version  measures  the  ability  to  change,  not  the  ability  to  change  your  ability  to 

change.  That's  for  the  future.) 

16.4  Possible  Lack  of  Quantitative  Information . 187 

[Suppliers  will  have  scant  idea  of  the  questions  you'll  be  asking.  There  are  additional 

costs  associated  with  education,  with  obvious  side  benefits.) 

16.5  Agility  and  Evolution . 188 

[Becoming  agile  may  require  a  more  serious  commitment  to  reinvention  than  most  firms 

are  willing  to  make.) 

Part  3,  Soft  Modeling  190 

[Part  3  is  for  the  reader  who  is  interested  in  social  and  cultural  issues  and  what  we've  done  about 

them.  Many  examples  are  in  this  part.) 

1 7  Abstract . 190 

18  An  Historic  Case . 191 

[The  primary  focus  of  this  section  is  the  thread  of  case  studies  revolving  around  the  movie 

production  business.) 

18.1  Military  Research  “Can"  Do's  and  Don'ts . 191 

[Defense  research  flubbed  up  on  the  can  opener.  Why?) 

18.2  Show  Me . 191 

[The  study  begins  with  an  interest  in  legal  agreements  for  movies.) 

18.3  The  Whale  of  Fortune . 192 

[The  U.  S.  dominates  the  important  world  whaling  industry.) 

18.4  Virtual  Whaler  Dealers . ■.  193 

|A  whaling  party  was  a  virtual  enterprise.) 

18.5  The  Guild . 194 

[Captains  were  the  owners  of  persistent  knowledge,  culturally  bounded.) 

18.6  The  Gilded . 195 

[An  agile  response  as  whalers  respond  to  the  gold  rush.) 

18.7  Oils  Well  That  Ends  Whale . 196 

[Another  agile  response  as  the  whole  industry  reinvents  itself.) 

18.8  Some  Lessons  Learned . 196 

[Culture  is  key.  In  this  case,  it  lead  to  trust-enabling  case  law.  The  culture  may  have  a  self¬ 
preserving  life  of  its  own.) 

19  Social  Issues  at  Work . 199 

[More  examples.) 

19.1  Waterworld . 199 

[One  Japanese-owned  studio  makes  a  bad  cultural  decision.) 

19.2  Indian  Software  Collectives . 200 

[Homogeneous  culture  is  key  to  fast  software  in  India.) 

20  Role  of  Culture  as  an  Agent . 202 

[Agility  agents,  especially  organizers,  act  in  a  social  medium.) 

20.1  The  Russian  Mafia . 202 

[Some  Russian  enterprises  are  agile  for  surprising  reasons.) 

20.2  An  Automotive  VE . 203 

I  [An  interesting  proposal  for  a  virtual  auto  plant  in  the  U.  S.,  now  in  China.) 

20.3  Defining  the  Culture . 205 

[Influencing  the  culture  can  incubate  agents.) 

21  Some  Necessary  Considerations . 206 
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|Some  characteristics  of  agile-producing  culture.) 

21.1  Diversity. . . : . 206 

[The  strongest  partnerships  are  those  among  wholly  different  partners.) 

21.2  Importance  of  Language  (and  Unimportance  of  Standards) . 206 

[Because  diversity  is  key,  simple  standards  may  be  bad.  Better  to  have  a  cheap  way  of  de¬ 
veloping  adaptive  interfaces  on  the  fly.) 

21.3  Hidden  Economic  Motivators . 207 

[Cultural  factors  may  dominate  the  strategy  of  the  enterprise.  Some  examples.) 

21 .4  Tlie  Role  of  Organized  Learning . 208 

[An  agile  organization  is  one  that  has  a  learning  culture.) 

21.4.1  Honesty  and  the  Investment  Community . 209 

[The  ability  to  judge  itself  seems  an  agile  cultural  trait.) 

21.4.2  The  Importance  of  Dyadic  Communication . 209 

[Even  in  the  largest  enterprise,  most  collaboration  is  between  two  people,  a  situa¬ 
tion  where  social  dynamics  dominate. [ 

22  Trust . 210 

[Trust  seems  to  be  a  common  cultural  descriptor  of  agile  systems.  We  explore  the  idea  in  this 

section. [ 

22.1  Bacl<ground . 210 

[We  exclude  social  and  cultural  issues  from  our  first  shot  at  metrics,  but  are  advised  they 

are  unavoidable.[ 

22.2  An  Example  of  the  Problem . 210 

[An  example  of  an  apparently  logical  action  undermines  trust.  There  is  a  difference  be¬ 
tween  trusting  agents  and  trusting  the  channels  among  agents.) 

22.3  Confidence  and  Trust . ,.211 

[There  are  two  definitions  of  trust.  We  contrast  the  two  here.) 

22.3.1  Confidence . 211 

[One  kind  of  trust  is  expected  repeatability.  But  this  has  problems  when  conditions 

change.) 

22.3.2  Trust . 212 

[Another  notion  of  trust  is  based  on  knowing  how  someone  might  behave.  This  is 

better  for  agility.) 

22.4  Agents  and  Channels . 213 

[Trust  in  agents  is  different  than  trust  in  the  communication  channel  among  agents.) 

22.4.1  Agents . 214 

[There  are  three  types  of  agents.) 

22.4.2  Channels . 214 

(Agility  is  related  to  the  connectivity  among  agents.) 

22.5  Trust  Metrics . 215 

[Our  basic  method  might  be  expanded  to  provide  metrics  for  trust  in  an  enterprise,  which 

are  also  tagged  to  processes  and  agents.) 

23  Cultural  Drivers  for  Legal  Issues  in  the  Defense  Community . 218 

[We  suggest  a  source  for  two  confliaing  paradigms  which  haunt  the  defense  industrial  base.) 

23.1  A  Key  Difference:  The  English  and  French  Engineering  Paradigms  . .  218 
[The  French  and  English  have  wholly  different  approaches  to  engineering.  These  are  cul¬ 
turally  based.  The  U.  S.  civil  sector  inherited  the  English,  while  the  militaiy  sector  inher¬ 
ited  the  French.) 

23.2  Lessons  for  Metrics . 221 

[Defense  lack  of  agility  is  caused  by  French  at  the  top,  English  at  the  bottom  of  enterpris¬ 
es.) 
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23.3  Law  Follows  Engineering . 222 

[The  two  engineering  paradigms  become  ensconced  in  two  differing  legal  systems,  also 
culturally  based.  Case  law  (as  in  the  movies)  is  a  trust-enabling  environmental  factor.) 

24  High  Concept  in  the  Supply  Chain . 225 

|We  return  to  movies  to  examine  lightweight  contraas  as  a  portable  technique.) 

24.1  Background . 225 


(We  revisited  the  movie  contaas.) 

24.2  The  Movie  Industry  as  a  Prototype . . 225 

(The  Japanese  consider  the  movie  business  a  portable  prototype,  both  after  the  war  and 

more  recently.) 

24.3  Hollywood  Evolves . 227 

(Hollywood  develops  the  packet-unit  production  system,  a  virtual  enterprise  system.  It 

depends  on  a  culturally  based  trust  communicative  shorthand.) 

24.4  High  Concept . 227 

(High  concept  defined  and  proposed  as  an  agility  strategy.) 

24.5  High  Concept  in  Organizing  the  VE . 229 

(We  report  on  how  the  cultural  shorthand  enables  agility.) 

24.5.1  What  it  Does,  How  It  Apparently  Works . 229 

(High  Concept  depends  on  and  feeds  its  cultural  base.) 

24.5.2  Connection  to  Lightweight  Contracts . 230 

(High  Concept  is  the  context  for  trust.) 

24.5.3  Agents  in  the  Strategy . 230 

(Agents  are  empowered  by  this  shorthand,  agents  keep  the  culture  vital.) 

25  Role  of  Defense  Sponsorship . 232 

(in  this  section  we  tie  ManTech  to  the  key  improvement  in  the  movie  industry  and  make  the 

general  case  for  military  sponsorship.) 

25.1  ManTech,  Movies  and  the  Spruce  Goose . 232 

(ManTech  may  be  responsible  for  the  key  ideas  of  High  Concept  trust  in  the  movie  busi¬ 
ness.) 

25.2  Why  Now? . 233 

(Agility  is  a  key  issue  in  defense,  especially  aerospace,  readiness.) 

25.3  Why  Government  Support? . 234 

)The  only  way  agility  tools  will  hit  the  general  supply  chain  is  through  third  party  (gov¬ 
ernment)  intervention.) 

25.4  Necessity  of  Government  Investment . 234 

(Agility  is  one  of  several  key  infrastructure  capabilities  that  are  in  the  national  interest.) 

25.5  Example  of  a  Bad  Investment . 236 


(But  infrastruaure  investments  need  constant,  diligent  management.) 

25.6  Why  the  Advanced  Research  Projects  Agency? . 236 

(ARPA  has  always  been  the  driver  for  high  risk/high  reward  infrastructure  technologies.) 

25.7  Why  Air  Force  ManTech? . 236 

(Air  Force  ManTech  has  a  deep  legacy  in  manufacturing  infrastruaure  generally,  and  agil¬ 
ity  issues  specifically.) 

26  The  Soft  Modeling/Soft  Mathematics  Problem  Stated . 239 
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(There  is  an  interesting,  well  funded  trend  in  epidemiology,  but  it  misses  satisfying  our 

rigorous  criteria.] 
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29  Physics  and  Behavior  for  BAST96 . 248 
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29.2  BAST96 .  250 
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29.3  Problem:  Soft  Metrics  for  the  Agile  Virtual  Enterprise . 252 
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29.3.1  The  Difficulty  for  BAST . 254 
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29.4.1  The  Problem . 255 
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29.4.3  A  Slightly  New  Perspective . 257 
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[Action  is  needed  because  we  can  relate  processes  and  process  intent  to  aaions. 

That  notion  of  intent  can  indude  the  intent  to  adapt  processes.] 

29.4.5  Agent . 258 

[An  agent  or  aaion  means  something  different  in  the  social/cultural  context.] 

29.4.6  Meme . 258 

I  We  suggest  memetics  as  a  metaphoric  framework  for  one  special  element  of  actions 

in  societies.) 

29.4.7  Relevance  to  BAST . 259 


[Can  we  action-like  memes  on  the  right  hand  of  situation  statements?] 


30  Results  of  BAST96 . 261 

|We  report  the  relevant  results  so  far  as  social/cultural  metrics  are  concerned.] 

30.1  Actons . 261 
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truary  I5,  1997 


24 


Table  Of  Contents 


|We  differentiate  between  tacit  information  and  the  soft  information  which  is  our  diffi¬ 
cult  problem.] 
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32  Future  Action .  269 
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32.1 .1 .2  Vertical  Information  Flow . 271 
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272 
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33  Abstract . 276 
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34.1  A  Serious  Problem . 277 
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[Though  beneficial  in  other  areas,  the  electronic  data  standards  effort  known  as 
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(The  legal  system  difference  can  be  traced  to  a  different  engineering  philosophy;  the  cus¬ 
tomer  controls  the  processes.] 
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Part  1 ,  Metrics  Handbook 


[Part  1  is  for  readers  who  simply  want  a  users'  view  of  the  metrics  and  how  they  work.] 


2  Abstract 

We  provide  an  executive  overview  of  the  metrics  with  an  example.  Details  on 
the  approach  are  given,  first  the  Reference  Model  which  is  central  to  the  first  step. 
In  describing  the  model,  we  review  some  case  studies  we  used  in  calibrating  the 
model.  A  review  of  the  second  central  element  of  the  process,  communicative  act 
modeling  is  given  in  some  detail. 

Finally,  we  introduce  a  process  not  central  to  the  metrics,  concerned  with  stra¬ 
tegic  brainstorming  for  agility.  We  devised  this  method  because  apparently  none 
existed. 
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3  Executive  Overview 

|A  single  chapter  overview  of  the  metrics  with  a  simple  example.  This  sertion  is  a  standalone  executive  over- 
view.) 

Though  general  ideas  about  agility  abound,  precious  few  formal  foundations  for 
the  new  discipline  of  engineering  agile  systems  have  been  available.  At  the  root  of 
this  need  is  the  lack  of  measures  or  metrics  to  evaluate  quantitatively  the  agility  of 
a  process  or  business  enterprise.  Here,  we  present  such  metrics,  together  with 
suggested  uses  for  building  a  discipline  to  engineer  dynamic  virtual  enterprises. 

3.1  The  Problem 

[A  brief  description  of  what  is  agility  and  why  we'd  want  to  measure  it.] 

Some  managers  claim  that  agility-the  need  to  respond  well  to  unexpected 
change**is  a  challenge  they’ve  been  facing  for  decades;  that  it  is  nothing  new. 
That’s  true,  though  the  rate  of  change  in  general  has  increased.  But  in  some  indus¬ 
tries,  unpredictable  change  is  now  the  premier  characteristic;  surprise  permeates. 

In  others,  for  instance  some  defense  sectors,  the  time  it  takes  to  develop  a  prod¬ 
uct  is  much  longer  than  the  generational  life  of  key  technologies  and  processes, 
and  an  inflexible  system  of  maintaining  the  supply  base  works  against  you.  Part  4 
starts  with  an  example  where  a  lack  of  agility  in  the  supply  base  is  the  primary  im¬ 
pediment  to  producing  a  system  to  a  long-standing  threat. 

As  the  need  to  deal  with  rapid  change  has  increased,  so  has  the  potential  for 
managers  to  engineer  their  business  enterprises  for  change  based  on  knowledge 
rather  than  instinct.  Responsiveness  is  becoming  recognized  as  a  part  of  overall  risk 
management  and  process  engineering  functions. 

Instincts  are  unreliable  in  some  market  sectors.  As  social  and  technical  clocks 
accelerate,  the  context  can  shift  quickly;  what  worked  yesterday  may  well  not  work 
today.  In  some  games,  the  tolerance  for  mistakes,  required  for  building  the  expe¬ 
rience  behind  instincts,  can  ill  be  afforded.  In  any  case,  the  management  and  in¬ 
vestment  community  will  always  prefer  reasoned  decisions  where  a  clear  rationale 
based  on  metrics  is  applicable. 

I’ve  sat  in  on  dozens  of  meetings  where  managers  say  they’re  convinced  of  the 
need  for  agility  in  their  strategy,  but  that,  once  they  get  beyond  the  motivational 
speeches,  they  just  don’t  know  what  to  do.  It’s  a  plain  fact  that  some  of  the  better 
managers  need  agility  and  are  ready  to  go,  but  they  just  don’t  have  the  tools  for 
acting  in  an  informed  and  decisive  way.  What  they  need  is  a  sort  of  black  box  into 
which  to  put  a  process  or  a  system  of  processes  and  get  back  a  number  measuring 
agility,  which  can  be  calibrated  to  the  (time  and)  cost  of  change. 

Change  is  old  news,  but  the  idea  of  carefully  engineering  an  enterprise  to  thrive 
in  change  is  new.  In  fact  it’s  a  radical  idea~so  radical  that  the  agility  community 
often  hides  this  novelty  rather  than  scare  the  meek.  Nonetheless,  it  is  a  radical 
lidea,  one  that  requires  new  tools,  some  themselves  also  radical,  and  new  types  of 
decisions  to  add  to  conventional  factors.  At  root,  decisions  are  based  on  tools  and 
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methods,  and  these  are  based  on  metrics.  Without  metrics,  no  one  can  make  the 
decisions  they  need  about  the  cost  of  agility  versus  its  effectiveness. 

Agility  is  like  insurance;  you  buy  it  to  counter  a  threat,  to  minimize  a  risk.  Agility 
in  one  direction  may  not  mean  agility  in  another;  in  fact  one  kind  could  counter 
another.  What  kind  and  how  much  are  questions  that  might  be  asked.  A  manager 
will  also  ask  whether  a  given  process  or  collection  of  processes  contributes  to  an 
agile  overall  strategy,  as  well  as  what  is  the  proper  balance  with  other  metrics 
(cost,  time,  quality  of  product)  in  a  careful  strategy. 

So  we  must  have  metrics  before  agility  can  become  a  strategic  factor  in  business 
planning.  And  it’s  likely  that  the  problem  will  be  difficult.  The  Defense  Advanced 
Research  Projects  Agency  (DARPA)  sponsored  us  to  work  on  this  problem  as  a  part 
of  their  Agile  Manufacturing  Initiative. 

3.2  Leveraging  Information  Theory 

[How  some  prior  work  measures  complexity  of  computing  algorithms,  why  we  chose  to  leverage  that  basis.] 

As  a  balance  to  the  number  of  intuitive  approaches  to  agility,  we  elected  to  work 
from  the  most  formal  applicable  perspective.  Most  formal  theories  of  systems 
which  involve  collaborative  agents  rely  on  information  theory.  The  branches  of  this 
science  which  interest  us  have  two  roots:  understanding  the  mechanics  of  lan¬ 
guage  behind  communication  and  characterizing  the  complexity  of  processes  in 
computer  programs. 

We  won’t  be  overly  technical  in  either  this  overview  or  the  whole  report.  What’s 
important  is  that  a  strong,  well-understood  mathematical  discipline  exists  which 
deals  with  a  formalized  view  of  processes  and  their  complexity.  Computer  scien¬ 
tists  contribute  to  this  mathematics  because  it  is  important  to  understand  whether 
one  algorithm  will  require  more  computer  cycles  than  another,  or  more  aptly, 
whether  an  algorithm  can  be  used  for  many  purposes  other  than  its  original  con¬ 
text,  and  what  would  be  the  complexity  of  the  program  used  to  make  the  change. 

Linguists  have  likewise  contributed  to  this  mathematical  foundation.  Among  the 
many  things  not  yet  fully  understood  about  language  is  exartly  what,  within  the 
ground  rules  of  languages,  contributes  to  what  elements  of  cooperation.  It’s  a  tur¬ 
bulent,  controversial  area,  but  at  the  core,  some  stable,  useful  mathematical  ideas 
have  been  developed  and  exercised;  these  have  been  added  to  information  theory. 

Our  strategy  has  been  to  take  this  formal  knowledge  and  leverage  it  into  the 
business  domain  to  deal  with  our  problem.  This  has  been  accomplished  with  some 
success  because,  while  agility  is  a  radical  business  idea,  the  mechanics  of  business 
are  a  simple  subset  of  the  larger  world  addressed  by  the  original  information  the¬ 
ories. 

Our  business  problem  assumes  that  every  participant  in  the  enterprise  is  work¬ 
ing  toward  a  uniform  goal  (business  success)  that  can  be  measured  quantitatively 
►in  dollars,  either  profit  today  or  profit  tomorrow.  We  do  not  assume  every  process 
as  measured  locally  contributes  directly  to  this  goal,  but  we  do  assume  that  each 
partner  does  so.  (Also,  we  do  not  assume  that  every  process  is  explicit  and  every 
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Enhanced  Core  Competencies 
Improved  WorkForce 
Intrinsic  Agility 

Figure  3-1  :Strategic  Considerations 

relationship  overt;  we  return  to  this  below  in  our  discussion  of  social  and  cultural 
dynamics.)  Activities  in  the  non-business  world  are  substantially  less  well  directed 
and  behaved,  so  the  business  domain  avoids  most  of  the  active  unknowns  and  con¬ 
troversies  among  working  information  theorists. 

A  common  view  in  this  information  world  is  to  see  only  two  main  items:  agents 
and  the  communicative  acts  that  transpire  among  them,  and  many  modeling  meth- 

Communicative  Act 


ods  are  based  on  this  same  simple  breakdown.  It  can  become  quite  complicated, 
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of  course,  as  subtle  distinctions  and  dynamics  are  added,  but  a  simple  version  of 
this  is  the  basic  concept  we  use.  For  us,  the  world  of  communicative  acts  describes 
information-based  collaboration. 

In  this  information  world,  it  is  helpful  if  what  each  node  does-what  the  commu¬ 
nication  is-is  captured  at  the  lowest  level  possible.  We  provide  this  by  breaking 
each  action  into  one  of  a  few  basic  communicative  acts.  The  taxonomy  we  use  has 
been  common  for  decades. 


Act 


Because  our  domain  is  business,  we  can  get  by  with  only  a  few  non-speech  acts. 
If  we  tried  to  measure  the  agility  of,  say,  armed  forces,  we  would  need  a  more  com¬ 
plex  non-speech  act  breakdown  than  ship-and-pay. 

Our  metrics  rely  on  a  simple  concept.  If  you  take  a  business  process  and  break 
it  down  into  its  agents  and  communications,  the  complexity  of  that  representation 
correlates  well  with  the  cost  of  changing  the  process.  And  the  relationship  is  well 
behaved  arithmetically,  so  that  resulting  metrics  can  be  considered  with  other 
metrics  in  strategic  planning,  risk  management,  and  enterprise  engineering  tools. 

3.3  Agility  Metrics 

[The  core  process  of  the  metrics  is  outlined  and  a  defense  aerospace  example  is  given.] 

Our  initial  task  was  to  find,  among  the  various  complexity  features  that  informa¬ 
tion  theory  defines,  a  small  number  which  have  the  following  characteristics: 

^They  capture  the  various  relevant  notions  of  complexity  that  relate  to  dynamic 
adaptive  coupling  (agility) 

iln  doing  so,  they  don’t  require  unneeded,  expensive-to-obtain  information 
about  the  enterprise 

}  4The  number  of  features  is  minimal 

^Each  feature  is  independent  of  the  others 

^They  are  useful  for  the  types  of  analyses  business  decisionmakers  perform 
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In  mathematical  words,  the  features  of  interest  are  complete,  sparse  and  or¬ 
thogonal,  which  characteristics  make  possible  the  useful  mathematical  operations 
that  we  need  (including  the  arithmetic  of  accounting).  We  have  found  those  com¬ 
plexity  features  which  relate  to  agility.  Combined,  they  provide  a  basis  for  that 
black  box  that  business  analysts  and  enterprise  engineers  need. 

To  describe  them,  we’ll  use  the  following  example.  The  table  shows  a  typical  ex¬ 
ample  process  entered  in  a  standard  tabular  form.  Each  row  in  the  table  denotes 
one  of  the  standard  communicative  acts. 


2| 

D 

A 

Now  that  you  mention  it,  we  might 

Inform 

1 

3i 

D 

A 

Tell  me  more 

Question 

1 

A 

B 

Do  you  have  skillsets  B’,  needed  for  N? 

Question 

6’  S 


CD 

O 


frt  utterance 


D  I  Might  you  have  a  need  tor  l\l? 


C9 

CD 

CD 

fS. 

CO 


Question 


Inform 


A  Do  you  want  us  to  develop  B’? 


A 

C 

If  1  do  A’  and  B  does  B’  or  B”,  can  we  do  N? 

Question 

2 

Jl' 

_ 

A 

B 

We  only  need  B’ 

101 

r.  ? 

A 

B 

Can  you  commit  to  B’ 

Hi 

B 

A 

We  can  commit 

BD 

Both  A  and  B  can  commit  to  A’  and  B’ 

D 

Would  you  like  us  to  address  your  need,  N? 

Inform 

6,8 

Question 

6 

Inform 

10 

Table  3-1 :  Breakdown  of  an  Example  Process 


The  process  modeled  is  a  candidate  case  for  delegated,  distributed  marketing 
by  an  Agile  Virtual  Enterprise’s  (AVE’s)  subordinate  partners.  Agents  A  and  B  are 
agents  somewhere  in  the  supply  chain.  A  is  a  particularly  astute  monitor  of  a  po¬ 
tential  customer.  Agent  C  is  in  the  prime  contractor,  say  a  senior  marketeer.  Agent 
*D  is  a  potential  buyer.  This  is  a  particularly  promising  process  for  agility,  one  which 
enfranchises  a  partner,  even  a  minor  one,  to  market  a  customer  on  the  behalf  of 
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the  AVE.  It  could  be  one  of  a  few  processes  upon  which  this  AVE  could  build  an 
agility  strategy. 

In  this  scenario,  Acme  Grinding  (A)  finds  a  new  need,  A  New  Jet  Engine  Thrust 
Nozzle  Design  (N),  of  which  the  customer.  Department  of  the  Air  Force  (D),  might 
not  be  fully  aware.  The  AVE,  which  contains  A,  B  and  C,  currently  cannot  meet  the 
need.  But  it  might  if  some  processes  change.  Perhaps  Basic  Casting  Co.  (B)  can  sat¬ 
isfy  part  of  the  new  need  by  developing  a  new  process  B'.  Or  maybe  something 
less,  a  smaller  change,  B”,  will  do  if  A  itself  makes  a  change  to  A'.  In  both  cases,  it 
is  unknown  to  A  whether  the  prime.  Consolidated  Aircraft  (C),  can  fill  in  the  other 
blanks,  either  by  itself  now,  by  changing,  or  by  finding  or  changing  other  partners. 
So  A  has  to  do  some  discovery  and  present  tentative  results  to  the  prime,  C,  for 
more  discovery. 

Perhaps  Basic  Casting  makes  nozzles  of  nonamium  for  Consolidated’s  new  air¬ 
craft,  which  Acme  cleans  and  treats.  Consolidated  and  the  Air  Force  selected  non¬ 
amium  over  newstuffium  because  of  the  finishing  costs.  Acme  learns  of  a  new 
finishing  process  (A')  which  might  change  that  decision,  and  greatly  reduce  the 
cost  of  the  aircraft,  so  much  so  that  a  competitor  to  Consolidated  could  (in  the  fu¬ 
ture)  design  a  better,  cheaper  aircraft. 

But  Acme  has  to  discover  whether  Basic  can  learn  to  make  a  clean  newstuffium 
part  (B'),  or  a  more  dirty  part,  using  a  less  radical  casting  process  B”.  We've  chosen 
this  example  because  it  assumes  trust  and  novel  reward  strategies;  these  would  be 
covered  in  another  process  which  would  be  evaluated  in  a  similar  way.  It  also  as¬ 
sumes  that  Acme  can  discover  the  cost  of  change  within  Basic,  probably  by  using 
the  metrics. 

The  table  shows  A  going  to  B  and  finding  out  what  B  can  do,  then  reporting  the 
results  of  potential  opportunity  and  capabilities  to  C  for  following  up. 

The  Figure  shows  the  same  process  in  a  specific  graphical  form,  called  a  Dooley 
Graph,  which  reveals  the  structure  of  the  communicative  acts  within  the  process. 
The  conversion  between  table  and  graph  is  straightforward  but  sometimes  unin¬ 
tuitive.  The  four  columns  on  the  right  of  the  table  are  an  aid  in  this  process,  which 
we  will  not  detail  here.  (We’ve  developed  a  little  example  tool,  that  we  call  Pome¬ 
granate,  to  perform  the  transformation  automatically.) 

Note  in  the  Dooley  Graph  that  some  nodes  are  linked  by  lightly  shaded  links 
which  are  not  communicative  acts  within  the  scope  of  the  process.  These  are  vir¬ 
tual  acts,  presumably  supported  by  other  processes  or  contexts  in  the  enterprise. 
The  number  and  type  of  such  virtual  linkages  forms  the  basis  for  a  related  set  of 
metrics  we  have  developed,  to  measure  trust.  These  are  not  discussed  here. 

There  are  two  features  of  this  graph  which  reveal  its  complexity;  hence,  those 
two  are  what  we  measure.  They  are  complete,  sparse  and  orthogonal,  constituting 
a  raw  measure  of  agility.  They  are: 

I  4The  number  of  nodes  and  the  complexity  of  each  node.  The  complexity  of  a  node 

is  the  number  of  other  nodes  to  which  it  has  a  communicative  link.  Figure  3-5 
tags  the  graph’s  nodes  and  links  with  these  numbers.  The  node  in  the  upper  left. 
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Figure  3-4:Dooley  Graph  of  the  Example 

for  instance,  is  a  two-node,  since  it  has  two  connections,  even  though  they  are  to 
the  same  node. 

The  example  has  12  nodes  which  break  down  into  four  nodes  which  connect  to 
one  other  node,  four  which  connect  to  two,  two  to  three  and  two  to  four.  The 
metric  derived  from  this  information  is  a  simple  sum  of  the  number  of  each 
nodes  raised  to  the  power  of  its  type.  For  instance,  there  are  four  two-nodes; 
since  these  are  two-nodes,  the  four  gets  raised  to  the  second  power,  4^  (it  gets 
squared). 

As  a  colloquial  shorthand  (providing  a  name  rather  than  a  formal  definition),  we 
call  the  sum  the  Distance  metric.  The  example’s  distance  metric  is 
4'  -1-424-2^-1-2^=44.  The  first  number  records  that  there  are  4  nodes  from  Figure  5 
that  are  labeled  1;  they  have  only  one  link  associated  \vith  them.  The  number  of 
linkages  is  also  the  power  to  which  the  count  is  raised,  in  this  case,  one.  There 
are  four  labeled  two,  so  that  produces  our  second  term,  four  raised  to  the  second 
power.  Two  of  the  disks  have  three  links,  and  two  have  four  links,  which  gives  our 
third  and  fourth  terms  of  2^  and  2*. 

The  higher  the  number,  the  higher  the  cost  and/or  time  of  changing  the  process. 
One  can  see  this  intuitively:  the  more  actors  involved,  and  the  more  each  one 
does,  the  harder  it  will  be  to  change  the  process. 

4The  number  and  complexity  of  links,  or  loops  within  the  process.  A  strict  applica- 
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Figure  3-5;Counting  Topological  Features  of  the  Example 

tion  of  this  metric  defines  a  loop  by  the  number  of  communicative  acts  (repre¬ 
sented  by  arrows)  there  are  before  the  utterance  is  resolved.  But  we  have  found 
that  an  accurate  approximation  simply  counts  the  apparent  loops.  For  instance, 
in  Figure  4,  acts  6  and  9  appear  visually  as  a  two  part  loop,  though  strictly  speak¬ 
ing  they  are  part  of  a  more  complex  communication.  So,  defined  this  simple  way, 
the  example  has  three  one-loops  (one-way  arrows)  and  five  apparent  two-loops. 
These  are  added  in  a  weighted  fashion  similar  to  the  distance  metric,  so  what  we 
call  the  Time  Delay  metric  for  the  example  would  be  3’+5^=26.  This  is  calcu¬ 
lated  in  a  way  similar  to  the  node-oriented  equation  except  this  time  its  arrow 
structures,  or  loops  that  are  counted.  Figure  5  shows  that  there  are  3  arrows 
which  are  dead-end  acts,  noted  with  the  number  one  to  show  that  they  are  loop 
structures  constructed  of  one  arrow.  These  three  raised  to  the  first  power  are  our 
equation’s  first  term.  There  are  five  loop  structures  composed  of  two  arrows, 
producing  our  second  term,  five  raised  to  the  second  power. 

The  resulting  two  numbers  (44  and  26)  are  simply  added  together  to  give  a  raw 
metric  of  the  process’s  agility;  the  higher  the  number,  the  lesser  the  agility.  This 
composite  metric  would  be  used  in  comparing  the  agility  of  processes  which  dif¬ 
ferentiate  two  potential  partners 
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There  are  associated  metrics.  Suppose  that  you  wanted  to  evaluate  the  cost  and 
time  associated  with  making  a  specific  change  from  one  process  to  another,  and 
you  have  a  model  of  both.  You  would  do  a  topology  match  between  the  two: 

^The  Topology  Match  measures  the  cost  of  changing  from  one  process  to 
another.  The  starting  (or  before)  process  is  the  baseline.  Here  we  count  nodes 
only,  the  percentage  of  nodes  in  the  target  process  that  have  exact  type  matches 
in  the  baseline.  Figure  3-6  shows  an  example,  using  our  familiar  process  as  the 
before  and  a  process  with  a  different  topology  as  an  after.  Six  of  the  twelve  nodes 
of  the  process  on  the  left  have  matches  with  the  process  on  the  right,  so  the  met¬ 
ric  is.50.  A  higher  number  indicates  lower  cost.  (The  relative  cost  of  adapting 
from  the  right  to  the  left  would  be. 86,  indicating  that  the  adaptation  would  be 
easier.) 


Figure  3-6:What  is  the  Cost  of  Mapping  from  the  Process  on  the  Left  to  That 

on  the  Right? 


Those  metrics  deal  with  individual  processes.  But  a  collection  of  agile  processes 
does  not  necessarily  add  up  to  an  agile  enterprise;  there’s  a  second-order  metric 
that  we  discuss  below.  But  in  many  cases-essentially  all  cases  where  the  extent  of 
agility  can  be  predicted  and  controlled-dealing  with  the  first-order  agility  we’ve 
described  is  sufficient.  Nonetheless,  every  process  carries  a  different  weight  In  the 
system.  The  following  two  metrics  characterize  that  weight: 

4lmportance  is  the  informal  name  for  the  comparison  of  the  distance  of  the  pro¬ 
cess  to  that  of  the  enterprise,  a  comparison  of  the  complexity  of  the  nodes.  Let’s 
say  that  the  entire  enterprise  has  an  (unweighted)  number  of 423,  then  12  simply 
divided  by  423  is  the  relative  importance  of  the  process  within  the  enterprise’s 
agility  profile.  That  number,  gets  compared  with  similar  weights  of  other 
processes  to  determine  how  they  are  added  to  evaluate  the  agility  of  the  entire 
enterprise  with  the  context  being  considered. 

similar  calculation  takes  place  to  determine  what  we  call  the  frequency  of  the 
process,  but  this  time,  the  process’s  unweighted  number  of  loops  is  compared  to 
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that  of  the  enterprise. 


Distance 

Total  number  of  weighted  nodes 

Time  Delay 

Total  number  of  weighted  loops 

Moveability 

Topology  match,  internal 

Importance 

Nodes  compared  to  the  VEs  total 

Frequency 

Loops  compared  to  the  VEs  total 

Table  3-2:  Summary  of  the  Intermediate  Metrics 


These  two  numbers  summed  provide  the  weighting  function  used  when  adding 
individual  key  processes  across  an  enterprise  to  understand  its  relative  agility.  The 
latter  two  numbers  do  not  require  that  all  processes  in  the  enterprise  (or  projected 
enterprise  configurations)  need  to  be  modeled  this  way  in  order  to  get  the  enter- 
prise-wide  distance  and  time-delay.  Because  the  importance  and  frequency  are  used 
relatively,  the  roughest  of  approximations  will  suffice. 

We’ve  validated  the  metrics  both  by  formal  reasoning  and  by  retrospectively  ap¬ 
plying  them  to  the  dozen  Agile  Virtual  Enterprise  Best  Agile  Practice  cases  inter¬ 
viewed  as  a  project  of  the  Agility  Forum  in  1995. 

The  key  metrics  are  the  first  two.  These  produce  a  raw  number  which  can  be 
used  as  a  relative  measure  of  agility  of  the  process.  Once  the  well-indexed  case 
bases  of  agile  practices  being  built  by  MIT,  the  Agility  Forum,  and  perhaps  others 
are  ready,  we  will  be  able  to: 

4CaIibrate  the  raw  agility  numbers  to  time  and  cost  numbers  In  specific  sectors. 
This  will  allow  managers  to  register  agility  with  other  cost/benefit  calculations  in 
a  balanced  strategy. 

4Extrapolate  numbers  into  functions.  This  will  allow  managers  to  follow  process 
design  guidelines  in  engineering  the  ideal  agility  into  processes,  again  following 
a  balanced  strategy. 

3.4  AVE  Model 

|An  earlier  step  of  the  method  depends  on  breaking  things  down  by  a  reference  model.  The  model  is  desaibed. 
Reference  is  made  to  the  cost  of  populating  the  model  and  a  case  study  to  determine  same.) 

The  metrics  are  Intuitive  and  simple  to  calculate  if  you  have  modeled  your  pro¬ 
cesses  in  the  nice  tabular  representation  which  leads  to  the  Dooley  Graph,  but  do¬ 
ing  so  may  not  be  how  you  naturally  see  things  in  your  organization.  To  prepare 
for  populating  such  a  table,  we  require: 

^  4That  there  be  a  standard  level  of  granularity  for  each  complete  process  (each 
table).  While  many  of  the  simpler  uses  of  the  metrics  do  not  depend  on  such  a 
standard  granularity,  the  more  interesting  do  (the  trending  and  pattern  matching 
of  processes  for  instance). 
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^That  process  dynamics  be  cleanly  segregated.  This  means  that  we  cannot  mix 
worlds  which  operate  according  to  different  principles;  truth,  for  example,  fol¬ 
lows  different  laws  in  legal,  physical,  and  business  process  domains.  The  same  is 
true  of  many  principles.  We  avoid  having  to  understand  and  manage  the  differ¬ 
ences  if  we  carefully  separate  them. 

The  Agile  Virtual  Enterprise  (AVE)  Focus  Group,  a  multi-year  open  workgroup 
sponsored  by  the  Agility  Forum,  tackled  this  problem.  A  standard  AVE  Reference 
Model  was  created  which  does  this  well.  We  won’t  describe  the  model  in  detail 
here,  rather  just  give  an  overview. 

The  model  is  a  two-dimensional  table.  The  (horizontal)  rovvs  give  a  breakdown 
of  the  decisionpoints  involved  in  conceiving,  forming,  operating  and  dissolving  a 
Virtual  Enterprise  (VE).  (The  VE  is  seen  as  the  more  difficult  case,  subsuming  the 
agility  concerns  of  conventional  enterprises.) 


Table  3-3:  High  Level  View  of  the  Reference  Model 


The  (vertical)  columns  provide  a  substantial  breakdown  concerning  the  infra¬ 
structures  of  the  VE,  the  major  categories  being  Physical,  Social/Cultural,  and  Ex- 
iplicit,  the  latter  including  Business  Processes,  Workflow,  and  Contracts/ 
Regulations.  Two  more  levels  of  breakdown  are  necessary. 

The  Row  (Decision  Point)  Breakdown: 
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Opportunity  Identification 
^Opportunity  Strategy 
^Opportunity  Exposure 
^Targeted  Marketing 
^Search 

Partner  Identification 
^Opportunity  Strategy 
^Partner  Performance  History 
^Partner  Search 

Virtual  Enterprise  Formation 
^Vision/Strategy  Development 
^Partner  Criteria  and  Selection 
^Enterprise  Metrics 
^Capitalization 
^Product  Liabilities 
^  Risk/Reward  Strategy 
^Operating  Strategy 
^Dissolution  Plan 

Virtual  Enterprise  Operation 
^Performance  Metrics 
<>Customer  Relations 
^Operating  Practice 

Virtual  Enterprise  Reconfiguration/Dissolution 
^Identification  of  Need 
^Residual  Liabilities 
^Dissolution  Plan 

The  Column  (Infrastructure)  Breakdown  of  interest: 

Social/Cultural  Infrastructure 

i  Social  and  Psychological  Laws 
^Community  Cultures 
EBusiness  Culture 

Legal/Explicit  Infrastructure 
EBusiness  Processes 

^Strategy  Development 
^Supervise  Risk/Reward  Process 
^Supervise  Engineering  Quality 
^Work  Scheduling 
^  Depth  of  Customer  Relations 
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^  Legal/Regulatory 

^Quality  Assurance  Agreements 
^  Risk/Reward  Contraas 
^How  the  Virtual  Enterprise  is  Represented 
^Assignment  of  New  Technology 
^  Labor  Agreements 
^WorkFlow  (Business  Plan) 

^Planning  Work  Breakdown  Assignments 
iWork  Breakdown  Responsibilities 
^  Monitoring/Adjusting  the  Work  Breakdown  Structure 
^Arbitration/Adjudication 
^Routine  Exception  Handling 

Physical  Infrastructure 

^Warehousing  and  Logistics 

^Virtual  Enterprise  Human  Collaboration 
^Virtual  Enterprise  Product  Collaboration 
i  Customer’s  Pipeline,  Product 
^Customer’s  Pipeline,  People 
^Raw  Commodities 
^Equipment 

^How  Modular 
^How  Reconfigurable 
^How  Scalable 
^How  Relocatable 
i How  Storable 
^Physics 

^Geographically  Limited  Processes 
^  Scale  Limited  Processes 
^Attention  Limited  Processes 
^Time  Limited  Processes 
^Accident  Limited  Processes 

Definitions  for  this  model  have  been  freely  and  widely  available  in  several  for¬ 
mats,  including  at  the  Agility  Forum’s  web  site.  We  won’t  review  the  model  in  de¬ 
tail  here;  the  important  point  is  that  it  gives  a  structure  for  the  analyses  such  as 
the  metrics.  Each  cell  in  the  model  deals  with  a  discrete  decision  (the  rows)  and 
involves  a  specific,  discrete  set  of  principles  (the  columns). 

Each  of  the  cells  defines  the  scope,  type,  and  dynamics  of  a  specific  process,  or 
candidate  process  that  a  VE  might  be  considering.  That  candidate  is  what  we  de- 
>scribe  in  the  Communicative  AcElDooley  Graph  format  described  in  the  first  part  of 
the  paper. 
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The  number  of  cells  can  seem  daunting,  but,  fortunately,  this  is  not  bad  news. 
By  studying  best  practices,  the  group  discovered  that  successful  agility  strategies 
focused  on  a  very  small  number  of  cells:  one  or  two  major  focus  cells,  a  half  dozen 
or  so  support  cells  and  a  few  cells  in  which  incompetence  could  create  problems. 

This  was  counterintuitive;  we  expected  that  agility  would  be  a  result  of  high 
scores  in  many  cells,  but  that  was  not  the  case.  Moreover,  the  cells  which  anchored 
3  strategy  varied  widely,  reflecting  different  leveragable  strengths,  business  strat¬ 
egies,  and  market  peculiarities.  So  there  are  few  generic  rules  of  thumb,  no  dummy 
list  for  painting  by  agility  numbers.  But  for  each  strategy,  only  a  few  cells  need  to 
be  modeled,  as  we’ve  described  above.  This  factor  tends  to  make  the  system-wide 
evaluation  of  agility  inexpensive. 

As  an  example,  consider  the  table  below.  Of  the  large  number  of  possible  cells 
to  consider  (1170),  using  the  art  of  consulting  skills  we  selected  20  that  are  likely 
to  host  an  agility  strategy  for  the  defense  prime.  Consolidated  Aircraft,  which 
shares  a  profile  with  our  case  study  prime. 


1.3  Targeted  Market 

2.3  Partner  Search 
3.6  Risk/Reward  Strategies 
t'4.1  Performance  Metrics 
5.1  Identify  Need  for  Change 


Table  3-4:  Specific  Cells  of  Interest 


The  cell  in  the  upper  left  is  the  cell  for  which  the  process  described  in  the  exam¬ 
ple’s  Dooley  Graph.  That  cell  concerns  business  processes  which  support  how  new 
markets  are  identified,  and  existing  markets  are  served  and  extended  through  es- 
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tdblishing  strong  snd  m63ningfu]  rolstionships  with  customers  which  are  support¬ 
ed  by  each  partner  on  the  behalf  of  the  VE. 

While  the  AVE  Reference  Model  is  intuitive  and  simple,  it  is  not  the  way  most 
enterprises  see  themselves.  Also,  by  Identifying  the  process  at  this  level  to  define 
the  communicative  acts,  you  fold  in  the  agility  strategy  and  Implicitly  the  nature  of 
the  change.  This  is  something  that  middle  level  managers,  one  important  target 
user  community,  may  have  trouble  envisioning. 

Finally,  interesting  and  useful  agility  involves  partners,  often  suppliers.  These 
suppliers  are  used  to  answering  questions  about  how  much  things  cost  and  how 
long  it  takes.  They  now  sometimes  answer  questions  about  quality,  but  many  may 
not  be  equipped  to  reveal  process  dynamics  at  the  level  we  need.  These  three  fac¬ 
tors  push  the  cost  of  using  the  metrics  up. 

How  expensive  it  will  be  to  see  your  processes  in  a  small  number  of  Dooley 
Graphs  is  an  important  Issue.  A  case  study  was  conducted  with  a  defense  aero¬ 
space  supply  chain,  audited  by  an  NSF  Agile  Manufacturing  Research  Center,  to 
better  understand  these  costs  in  a  real  scenario. 

3.5  Use  of  the  Metrics 

|A  few  ways  of  employing  the  metrics  are  listed.) 

There  are  a  variety  of  ways  that  the  metrics  might  be  employed. 

The  easiest  way  is  the  one  examined  in  the  case  study,  that  of  building  a  supply 
chain  with  a  specific  type  and  extent  of  agility.  In  this  case,  you  presumably  know 
the  general  type  of  change  and  have  a  general  strategy  for  response  that  leverages 
corporate  strengths. 

The  case  study  deals  with  a  common  problem  with  complex  systems:  The  devel¬ 
opment  time  of  the  product  is  much  longer  than  the  rate  at  which  new,  important 
technologies  evolve.  Best  practices  dictate  that  you  build  your  supplier  chain  early 
and  involve  them  Intimately.  But,  as  the  product  evolves,  that  supply  chain  needs 
to  be  agile,  not  artificially  limiting  the  processes  to  commitments  made  early.  Be¬ 
cause  the  product  in  this  case  is  a  military  weapon  system,  we  also  have  the  pos¬ 
sible  requirement  for  rapid  refinement  of  its  mission  profile. 

In  this  use,  the  metrics  tell  you  which  processes  are  more  agile  (based  on  your 
local  definition  of  the  need  for  agility).  Where  you  are  building  an  agile  supplier 
base,  it  can  tell  you  which  supplier’s  processes  give  you  the  agility  you  need,  both 
as  individual  processes  and  within  the  VE-level  systems  context. 

As  we’ve  noted,  if  you  have  a  case  base  which  is  applicable,  the  raw  agility  num¬ 
bers  can  be  converted  to  time  and  cost  numbers  for  a  related  use.  Suppose  that 
you  wanted  to  evaluate  the  time  and  cost  of  changing  from  one  set  of  processes 
to  another.  For  instance,  from  a  prime’s  current  processes,  plus  those  of  a  tenta¬ 
tive  supplier  set,  you  may  want  the  time  and  cost  of  changing  to  another  set  in  re¬ 
sponse  to  change.  (This  would  include  the  savings  of  the  agility  gained  within  the 
capability  of  current  processes). 
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In  this  use,  you  supply  a  process,  you  get  back  a  number  measuring  its  intrinsic 
agility.  As  previously  noted,  we  have  a  prototype/example  tool  that  does  the  com¬ 
putation  automatically. 

In  the  system-level  view,  one  would  combine  all  of  the  key  processes  according 
to  their  weights  to  evaluate  the  agility  of  the  enterprise  (for  that  one  change).  A 
simple  spreadsheet  can  do  this,  but  we  have  a  different  system-level  tool  underway 
that  supports  this  and  the  following  as  well. 

Because  you  won’t  be  certain  what  the  exact  change  will  be,  you  may  want  to 
do  a  statistical  analysis  of  the  likely  changes  to  be  encountered.  These  might  be 
based  on  the  tools  used  by  the  insurance  industry  to  model  risk.  A  spectrum  of  po¬ 
tential  needs  will  result,  with  a  spread  of  potential  processes  and  process  needs 
that  might  be  brought  into  play.  Sophisticated  tools  already  exist  to  perform  cost/ 
benefit  analyses  using  extrapolation  and  simulation,  if  the  responses  are  well 
formed  functions.  Our  metrics  are  these  kinds  of  functions:  continuous  agility 
functions  resulting  from  a  family  of  related  processes. 

The  way  you’d  look  at  a  supplier  or  an  enterprise  In  this  view  is  not  based  on  a 
single  threat  or  opportunity,  but  a  statistically  distributed  collection  of  possible 
events  and  options. 

The  movie  industry  does  a  similar  type  of  analysis  when  putting  together  pro¬ 
duction  VEs.  When  evaluating  the  potential  profitability  of  certain  firms,  the  in¬ 
vestment  community  does  similar  work.  The  key  in  the  investment  community  is 
knowing  how  likely  a  firm  is  to  be  profitable  in  the  future,  never  mind  now.  In 
many  sectors,  this  means  the  ability  to  survive  and  thrive  in  turbulence. 

The  most  interesting  use  of  the  metrics  is  to  go  beyond  evaluating  processes,  to 
suggest  more  agile  processes,  or  to  refine  existing  processes,  then  to  simulate/ val¬ 
idate  the  results.  That  is  the  direction  planned  for  our  future  work,  which  will  le¬ 
verage  other  tools.  Including  some  under  development  by  the  sponsored  agility 
community. 
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4  The  Agile  Virtual  Ente  -prise  Reference  Model 

|A  few  ways  of  employing  the  metrics  are  listed.| 

4.1  The  Process  of  Gene  rating  the  Reference  Model 

(Hundreds  of  people  helped  create  and  validate  the  model.  Some  summary  profiles  of  who  and  how  are  given.) 

The  Metrics  Project  was  incubated  within,  and  guided  by  a  large  group  of  con¬ 
cerned  users  and  researchers.  The  way  that  the  Project  was  conducted  was  novel: 
some  elements  of  the  project  required  focused  effort  by  experts,  who  brought 
work  to  the  group  to  be  validated.  But  a  major  part  of  the  work  was  actually  con¬ 
ducted  by  the  group,  the  creation  and  validation  of  a  Reference  Model  and  accom¬ 
panying  definitions  for  w  ide  variety  of  Virtual  Enterprises.  This  new  model  was 
needed  because  existing  perspectives  didn't  provide  adequate  focus  for  the  new 
goal  of  engineering  and  managing  agility  in  a  quantitative  way.  This  section  de¬ 
scribes  the  Reference  Model. 

The  Group  consisted  of  two  parts:  a  dedicated  group,  involving  about  150  peo¬ 
ple  which  met  about  25  times  over  three  years  for  two  days  each  meeting.  These 
meetings  rotated  around  the  country,  and  were  conducted  under  the  auspices  of 
the  Agility  Forum  as  the  Agile  Virtual  Enterprise  Focus  Group,  renamed  in  its  final 
year  the  AVE  Enterprise  Development  Group.  Logistics,  advertising  and  support 
were  handled  by  the  Forum.  As  well,  the  Forum  took  detailed  notes,  which  were 
both  mailed  to  a  large  list  and  published  on  the  Web  in  order  to  keep  all  parties 
current. 

The  group  was  facilitated  by  Jim  Jordan  of  the  Consortium  for  Advanced  Manu¬ 
facturing,  International;  in  the  final  year  he  was  joined  by  jerry  Rosser  of  Hughes 
Missile  Systems.  Members  of  the  group  were  from  the  following  organizations: 

4Small  Manufacturers 
4Agile  Web 
^Associated  Fiberglass 
4Ceco  Corp. 

^Contemporary  Design 
4Hehr  Power  Systems 
4HighTech  Marketing 
4Kavco  Industries 
4Lider  and  Associates 
4 Process  Consulting 
4Rheaco  Inc. 

4Tex  Direct 
4Sherpa  Corp. 

4 Symbiotic  Resources 
4Web  Pipeline,  Inc. 

4Large  Firms 
4AT&T 
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^Boeing  Commercial  Airplane  Group 
^Boeing  Military  and  Space 
4  Boeing  Rocketdyne 
^ Deere  &  Co. 

^Dupont  Advanced  Material  Systems 
^Eastman  Kodak 
^Ford  Motor  Company 
^Goodyear  Tire  and  Rubber 
^Hughes  Missile  Systems  Co. 

^H.  R.  Textron 
^IBM 

^Lockheed  Martin 

^Lockheed  Martin  Vought  Systems 

^Lockheed  Missiles  and  Space  Co. 

^Mack  Truck 

^Martin  Marietta 

^Metropolitan  Edison  Company 

^Newport  News  Shipbuilding 

i Northrop  Grumman 

^Raytheon 

^Sikorsky 

^Steelcase 

iTexas  Instruments 

iU.  S.  Steel 

^Westinghouse  Electric 
^Consultants,  Services,  Infrastructure 
4:2  Technologies,  Inc. 

^Agility  Forum 
^Andersen  Consulting 
^Arthur  D.  Little,  Inc. 

^Ben  Franklin  Institute 

^Center  for  Manufacturing  Competitiveness 

^CommerceNet 

^Competitive  Technologies  Inc. 

^Conduit,  Electronic  Delivery  Systems 
^D Ancona  &  Pflaum 
4  EDS 

^Enterprise  Agility  International 
^Executive  Action  Group 
^FKW  Incorporated 
^Gemini  Industries 
^Gaudiouse  and  Associates 
^Global  Strategic  Solutions 
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^Gunneson  Group  International,  inc. 

^ Hall  &  Associates 
^IBM 

^Intelligent  Systems  Technology  Inc. 

^Institute  of  State  and  Regional  Affairs  (PA) 

^Jim  Bronson 

^Knowledge  Based  Systems  Inc. 

^Lockheed  Martin  Palo  Alto  Research  Center 
^Manufacturing  Application  Center 
iMantech  International 
^ Menlo  Park  Ass. 

^Pennsylvania  MILRITE  Council 
^Schnader,  Harrison,  Segal  &  Lewis 
^Society  for  Manufacturing  Engineers 
^Strategic  Business  Management 
^Symbiotic  Resources 
^Telart  Technologies 
^The  Schraff  Group 
^VFD  Consulting 
^Virtual  Learning  Center 
^Researchers 

^Aerospace  Agile  Manufacturing  Research  Center 
^Arizona  State  University 

^Consortium  for  Advanced  Manufacturing  International 
^Cornell  Theory  Center 
^Georgia  Institute  of  Technology 
^Illinois  State  University 
^Industrial  Technology  Institute 
^Institute  of  Advanced  Manufacturing  Sciences 
^National  Center  for  Manufacturing  Sciences 
i  National  Institute  of  Standards  and  Technology 
^Pennsylvania  State  •  Harrisburg 
^Sandia  National  Labs 
^Sirius-Beta 
^University  of  Indiana 
^University  of  South  Dakota 
4  University  of  Texas  -  Arlington 
^University  of  Texas  -  Austin 
^Western  Kentucky  University 
^  ^Work  and  Technology  Institute 

This  group  included  representation  from  a  critical  mass  of  other  sponsored  agil¬ 
ity  projects: 
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^The  AIMS  Project:  a  demonstration  of  automated,  intelligent  infrastructure  for 
the  supply  chain  lead  by  Lockheed 

^The  Agility  Handbook  Project,  led  by  Competitive  Technologies,  Incorporated 
^The  Lean  Aircraft  initiative,  led  by  MIT 

^The  Affordable  MuItiMissile  Manufacturing  Program,  being  performed  by  four 
teams:  Hughes/Texas  Instruments,  Raytheon,  Lockheed  and  Loral 
4The  AgileWeb  experiment  in  a  Virtual  Enterprise 

^The  Next  Generation  Manufacturing  Systems  Program,  managed  by  CAM-1  for 
the  international  Intelligent  Manufacturing  System  initiative 

^The  similarly  named  Next  Generation  Manufacturing  study  being  conducted  by 
many  groups,  managed  by  the  Forum 

^Two  of  the  three  NSF  Agile  Manufacturing  Research  Centers  (and  many  of  their 
projects  which  we  won't  list  here) 

Complementing  this  group  was  a  much  larger  virtual  AVE  group.  The  legacy  of 
the  metrics  project  involved  some  predecessor  studies  which  involved  a  substan¬ 
tial  number  of  researchers.  Most  of  these  offered  to  contribute.  We  placed  a  large 
number  of  issue  papers  on  a  central  site  which  was  provided  by  the  Forum,  and 
solicited  input  through  an  email  discussion  list.  The  list  was  also  seeded  with  cer¬ 
tain  problem  issues.  A  robust  traffic,  perhaps  600  messages,  has  been  maintained 
both  within  the  list  and  via  private  messages  discussing  list  issues. 

Subscribers  to  the  list  were  from  the  following  host  machine  addresses,  which 
give  some  indication  as  to  their  nature.  For  instance,  we  can  see  that  most  are  re¬ 
searchers,  and  a  heavy  international  participation  was  maintained.  What  is  not  ap¬ 
parent  is  the  nature  of  subscribers  to  commercial  internet  services.  The 
breakdown  among  the  three  or  four  dozen  people  represented  in  this  category  is 
in  the  same  proportions.  One  of  the  America  On  Line  (AOL)  participants  translated 
and  widely  rebroadcast  traffic  within  japan. 

4Non-United  States 

imlb.dmt.csiro.au  (Australia) 
iinfo.fundp.ac.be  (Belgium) 
ieunet.be  (Belgium) 
iax.ibase.org.br  (Brazil) 
iift.ulaval.ca  (Canada) 
iie.utoronto.ca  (Canada) 
ilia.di.epfl.ch  (China) 
isap-ag.de  (Germany) 
iiff.fhg.de  (Germany) 
iira.uka.de  (Germany) 
iitmi.cgs.fr  (France) 
itm.tue.nl  (Holland) 
iswi.psy.uva.nl  (Holland) 
ildt.unit.no  (Norway) 
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^comu4.auckIand.ac.nz  (New  Zealand) 
^irl.cri.nz  (New  Zealand 
ilysator.Iiu.se  (Sweden) 
ibath.ac.uk  (United  Kingdom) 
iaiai.ed.ac.uk  (United  Kingdom) 
iaiai.edinburgh.ac.uk  (United  Kingdom) 
idcre.leeds.ac.uk  (United  Kingdom) 
inewcastle.ac.uk  (United  Kingdom) 
iwpmail.paisley.ac.uk  (United  Kingdom) 
istrath.ac.uk  (United  Kingdom) 
izeus.ucab.edu.ve  (Venezuela) 
i Commercial  Services 
iaol.com 
icompuserve.com 
idelphi.com 
iepix.net 
iinfi.net 
imcimail.com 
imetronet.com 
iix.netcom.com 
ipart.net 
icup.portal.com 
iradiomail.net 
isiol.net 
izilker.net 
iwell.sf.ca.us 
iUniversities/Non-profits 
iasu.edu 

iresearchl.asu.edu 

iviolet.berkeley.edua 

icgs.edu 

iunix.cie.rpi.edu 

ivax.clarku.edu 

iandrew.cmu.edu 

ics.cmu.edu 

itc.comell.edu 

iecsuc.ctstateu.edu 

igsvms2.cc.gasou.edu 

igtri.gatech.edu 

isurya.tfe.gatech.edu 

iseas.gwu.edu 

iuhavax.hartford.edu 
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^indtech.it.ilstu.edu 

^isi.edu 

^lehigh.edu 

^mit.edu 

^ai.mit.edu 

^tx.ncsu.edu 

^pucc.princeton.edu 

^psu.edu 

^quark.arl.psu.edu 

^psuvm.psu.edu 

^rpi.edu 

^kiku.stanford.edu 

^sumex.stanford.edu 

^tamu.edu 

^uc.edu 

^udri.udayton.edu 
^uxl. cso.uiuc.edu 
^glue.umd.edu 
4uog9.uog.edu 
4skinner.cs.uoregon.edu 
4arri.uta.edu 
4icc.utexas.edu 
4agiIityforum,org 
4cfi.org 
4chpc.org 
4ida.org 
4iti.org 
4scra.org 
4snap.org 
4wti.org 
4  Government 

4hq.doe.gov 

4mail.arc.nasa.gov 

4pioneer.arc.nasa.gov 

4qmgate.arc.nasa.gov 

4pop500.gsfc.nasa.gov 

4ulabsgi.gsfc.nasa.gov 

4nsf.gov 

4nist.gov 

4cme.nist.gov 

4enh.nist.gov 

4ornl.gov 

4sandia.gov 
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^  isrc.sandia.gov 
^acq.osd.mil 
^arpa.mil 
^ml.wpafb.af.mil 
^picard.ml.wpafb.af.mil 
^US  Businesses 

^atc.mke.ab.com 

^  gcuxj.att.com 

^atc.boeing.com 

^  kgv2.bems.boeing.com 

^  pss.boeing.com 

^  ctaeng.com 

^  ctc.com 

^  dacom.com 

^daina.com 

^  deere.com 

^  dttus.com 

4ford.com 

4e7sa.epi.syr.ge.com 

4julius.crd.ge.com 

4macgwl.crd.ge.com 

4cmsa.gmr.com 

4ccgate.hac.com 

4ccmail.emis.hac.com 

4halnet.com 

4src.honeywell.com 

4i-a-i.com 

4vnet.ibm.com 

4watson.ibm.com 

4ibmmail.com 

4iti-oh.com 

4kbsi.com 

4emerald.kbsi.com 

4vega.kbsi.com 

41imitpt.com 

4aic.lockheed.com 

4mm.rdd.lmsc.lockheed.com 

41vs-emh.lvs.loral.com 

4metsci.com 

4den.mmc.com 

4caemacl  S.msd. ray.com 

4mv.mv.com 

4ontek.com 
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^pa-consulting.com 

^ptib.boston.research.panasonic.com 

^network-master.perceptronics.com 

^philabs.philips.com 

4tasc.com 

4  galiieo.tracor.com 

4woIfF.com 

4einet.net 

There  were  many  special  workshops  and  consultations  at  specific  sites  with 
groups,  companies  and  other  projects,  which  we  will  describe  elsewhere,  each  in 
their  proper  place.  What  we  wanted  to  do  here  was  give  some  credit  for  the  sub¬ 
stantial  work  and  wisdom  which  created  and  validated  the  Reference  Model  which 
we  describe  below.  It  constitutes  effort  which,  in  this  element  alone,  leveraged  the 
government  investment  many  times. 

All  of  this  document,  in  various  drafts  of  parts,  was  circulated  by  various  means. 
Email,  which  is  limited  to  text  only,  forced  us  to  rely  heavily  on  precise  use  of 
words  rather  than  graphics,  which  often  are  more  ambiguous. 

4.2  The  Reference  Model 

[The  structure  of  the  model  is  reviewed  in  detail.] 

With  the  help  we  note  above,  the  various  generic  processes  of  the  VE  have  been 
broken  down  in  a  way  that  is  both  generally  useful  for  agility  considerations,  and 
also  specifically  supports  the  first  step  of  our  process. 

The  conventional  views  of  the  enterprise  as  a  collection  of  functions  (personnel, 
manufacturing,  etc.)  or  resources  (people,  machines,  intellectual  property)  are  not 
particularly  useful  in  considering  agility.  Instead,  what  is  of  interest  are  decompo¬ 
sitions  based  on  value-added  processes  and  capabilities  to  provide  that  value-add¬ 
ed. 

Toward  that  end,  the  life-cycle  of  the  VE  has  been  broken  down  into  the  follow¬ 
ing  major  processes.  Each  process  involves  decisions;  these  decisions  use  tools  and 
methods  which  are  informed  by  our  metrics.  Each  of  the  categories  and  subcatego¬ 
ries  noted  below  capture  the  process  involved  when  a  decision  is  made.  A  decision 
in  this  context  is  one  which  involves  cost  and  commitment. 

The  model  is  usually  represented  as  a  matrix  at  its  high  level  categories.  The 
rows  are  key  decisions,  the  columns  are  infrastructures. 

First  we  describe  the  processes.  These  are  organized  by  the  life  cycle  of  the  VE, 
from  birth  to  death.  The  major  breakdown  is  roughly  chronological,  but  the  divi¬ 
sions  below  that  are  not. 

Then  we  define  the  infrastructures.  Differences  among  infrastructures  require 
isome  special  attention  by  the  reader;  a  more  rigorous  breakdown  and  definitions 
are  used  here,  and  some  terms  may  differ  from  their  more  informal  meanings.  The 
goal  here  is  to  tease  different  underlying  mechanics  into  different  categories;  for 
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|_Oppoi1u^2^ 


_Ent^omTatiorj--^^  Operatioir^-^  Ent  Reconfig. 


Figure  4-1  :Major  Life  Cycle  Categories 


instance,  the  things  that  bind  a  VE  culturally  are  quite  different  in  nature  than 
those  that  tie  things  legally  or  by  business  processes.  The  importance  of  making 
these  distinctions  pays  off  later. 

In  both  axes  of  the  model,  we  worked  hard  to  fit  all  manner  of  business  models 
and  market  sectors.  The  model  at  the  high  levels  has  been  validated  in  a  wide 
range  of  for-profit  enterprises.  The  lowest  level  of  detail  in  the  infrastructure  is  do¬ 
main  dependent;  details  of  aircraft  enterprise  infrastructures  differ  from  those  of 
movie  or  food  sectors  for  instance. 

Finally,  we  give  some  examples  of  specific  process  decisions,  specific  cells  in  the 
matrix,  which  might  be  made  by  an  enterprise. 

All  of  this  depends  on  a  large  collection  of  definitions,  qualifiers  and  special  con¬ 
siderations.  Rather  than  encumber  the  reader  at  this  point,  we've  collected  these 
in  Part  2.  Among  other  things,  you  will  find  there  the  definitions  of  agility,  Virtual 
Enterprise,  metrics  and  such  on  which  we  depend. 

The  life  cycle  processes  are  listed  here  as  five  main  categories,  each  with  sub- 
categories. 


4.2.1  Process  Category  1:  Opportunity  Identification 

(Components  in  the  model  dealing  with  how  a  prospective  Agile  Virtual  Enterprise  identifies  whether  an  oppor¬ 
tunity  exists  and  what  its  nature  is-l 

The  main  category  assumes  that  some  agent,  either  a  potential  lead  for  an  AVE 
or  some  tentative  collection  of  contributed  experts,  has  the  charter  to  identify,  re¬ 
fine  and/or  characterize  the  opportunity.  This  could  be  a  broker  who  has  no  capa¬ 
bility  cogent  to  the  AVE’s  operation.  But  the  simplest  case  is  probably  the  most 
prevalent  today:  identification  and  refinement  of  an  opportunity  by  one  firm  which 
has  a  key  relevant  core  competency.  Then  that  firm  seeks  to  fiilly  understand  the 
characteristics  of  the  opportunity  to  define  the  requirements  of  the  AVE  which 
must  be  formed  in  response. 

Processes  in  this  first  category  may  proceed  simultaneously  with  the  those  of 
the  second  Partner  Identification,  with  a  better  understanding  of  the  capabilities 
►of  a  future  AVE  informing  an  understanding  of  the  market/opportunity.  As  an  op¬ 
tion,  simulation.  Virtual  Manufacturing,  can  be  used  to  support  both  of  these  two 
categories. 
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4.2.1. 1  Opportunity  Strategy 

In  order  to  identify  an  opportunity,  the  identifying  agent  needs  to  have  a  strat¬ 
egy.  The  strategy  must  be  explicit  and  well  reasoned,  because  results  from  the 
strategy  need  to  be  understood  and  adopted  by  potential  members  of  the  AVE. 
There  should  be  no  question  of  principles  in  the  strategy;  otherwise,  each  poten¬ 
tial  member  would  have  to  independently  conduct  their  own  analysis.  The  forma¬ 
tion  of  the  AVE  would  be  unnecessarily  encumbered. 

Within  the  strategy,  there  should  be  a  means  for  protecting  the  disclosure  of  de¬ 
tails  of  the  opportunity  to  potential  partners,  because  full  disclosure  could  mean 
empowering  a  competitor.  The  assumption  is  that  market  information  will  be  dis¬ 
tributed  among  firms,  at  least  in  the  Type  1  AVE,  so  that  a  combined  overview  must 
be  synthesized  from  several  sources. 

Relating  to  the  above,  early  in  the  entire  process  there  must  be  a  consistent  un¬ 
derstanding  of  who  is  the  lead  for  the  AVE  (at  least  for  this  phase).  There  may  be 
brokers  and  consultants  involved  who  are  specialists  in  the  strate^.  The  strategy 
should  be  based  on  a  consistent  method  for  defining  and  determining  core  com¬ 
petencies.  There  will  probably  be  a  simple  relationship  between  characteristics  of 
the  opportunity  (as  defined  by  the  strategy)  and  core  competencies  of  the  part¬ 
ners. 

The  strategy  also  needs  to  incorporate  a  vision  of  what  constitutes  success.  This 
definition  of  success  will  form  the  basis  for  many  of  the  processes  which  follow. 
Finally,  the  strategy  must  have  a  way  of  determining  whether  the  opportunity  is  a 
strong  candidate  for  being  addressed  by  a  feasible  AVE.  At  this  point,  the  AVE  cri¬ 
teria  are  probably  unknown. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 
^Responds  quickly  (appropriately  fast) 

^Forward,  panoramic,  view  of  market  opportunity 

^Explicit,  well  reasoned,  and  consistent  process  for  opportunity  ID/assessment 
^Continually  assess  opportunity  &  competition 
^Accommodates  continual  and  unexpected  change 
4 Repeatable  method  for  applying  competency  definitions  to  partners 

4.2. 1.2  Exposure 

Independent  of  the  strategy  (which  is  analysis  oriented),  there  needs  to  be  a  col¬ 
lection  of  actions.  This  and  the  remaining  subcategories  represent  various  types  of 
actions  supporting  opportunity  identification. 

The  lead  should  have  an  exposure  mechanism  and  use  it  to  inform  the  custom- 
er(s)  that  there  is  an  intent  to  address  the  opportunity.  Ideally,  the  customer  would 
>have  a  role  in  the  AVE.  Simultaneously,  actions  must  be  taken  to  expose  intent  and 
information  with  potential  partners.  How  this  advertisement  occurs  may  be  differ¬ 
ent  in  the  future.  For  now,  it  is  likely  to  be  critical  in  successfully  forming  the  AVE 
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and  addressing  the  opportunity.  It  may  be  that  an  entity  will  advertise  its  intent  to 
address  a  class  of  opportunity  rather  than  a  specific  opportunity. 

Agility  will  result  if  the  exposure  can  be  to  many  customers,  for  many  trial  situa¬ 
tions,  at  low  cost.  It  is  also  essential  that  fast  action  can  be  taken  when  the  situa¬ 
tion  looks  promising.  Such  speed  infers  that  a  pre-AVE  situation  can  be  evaluated 
by  sufficiently  high  confidence  metrics  to  commit  resources. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Multiple  mechanisms  to  inform/expose  customers  (internal  and  external)  that 
there  is  an  opportunity  and  an  intent  to  address  the  opportunity 
^individual  core  competencies  advertised 

4.2. 1.3  Targeted  Marketing 

There  is  a  collection  of  actions  which  may  actually  intervene  in  the  marketplace 
to  help  incubate  or  firm  up  an  opportunity.  This  process  is  where  the  customer  be¬ 
comes  integrated  into  the  AVE  at  an  early  stage  to  incubate  conditions.  The  pro¬ 
cess  will  be  more  sophisticated  than  opening  a  communication  channel,  since 
many  customers  may  not  know  what  could  be  possible,  or  not  have  recognized 
changing  conditions. 

This  process  includes  the  actions  employed  that  clarify  the  needs  and  match 
them  to  core  competencies  in  the  AVE,  effectively  defining  the  need  for  AVE  part¬ 
ners.  The  result  is  a  solution  in  response  to  the  need.  The  lead  may  go  through  a 
process  of  educating  the  customer(s)  to  help  create  the  demand  for  an  opportuni¬ 
ty.  Perhaps  the  definition  can  be  directed  to  maximize  the  competitive  advantages 
addressed  by  the  potential  core  competencies  of  the  AVE. 

An  AVE  will  almost  certainly  include  the  customer  in  the  partnership  in  some 
way  beyond  a  buyer-seller  relationship.  Ideally,  some  core  competencies  in  the 
customer  base  will  be  leveraged  to  advantage. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Insight  to  changing  key  buying  factors 

^Initiator  may  educate  the  customer  to  help  create  the  market  demand  for  an 
opportunity 

^Leverage  competencies 

4.2. 1.4  Search 

Sometimes  the  opportunity  is  not  apparent,  as  is  implied  in  the  two  subcatego¬ 
ries  noted  above.  Regardless,  each  firm  (or  stable  partnership)  should  be  constant¬ 
ly  searching  for  new  ways  to  leverage  its  competencies.  Therefore,  there  will  be  a 
set  of  processes  which  scours  new,  perhaps  unconventional  markets  empowered 
>by  new  partnerships.  This  collection  of  processes  will  vary  depending  on  the  sector 
and  the  creativity  of  the  organizations. 
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Apparently,  the  search  in  the  AVE  context  will  assume  capabilities  from  new 
partnerships.  These  will  come  either  from  strawman  partners  or  generic  capabili¬ 
ties.  There  needs  to  be  science  employed  (based  on  the  strategy)  in  order  to  eval¬ 
uate  tentative  opportunities.  Because  the  costs  of  AVE  are  different  from  non- 
AVEs,  this  science  (however  implemented)  may  be  a  key  competitive  tool. 

As  with  Opportunity  ID:  Exposure,  an  AVE  will  be  simultaneously  investigating 
many  possibilities,  including  very  unfamiliar  ones.  It  will  leverage  many  short  term 
relationships  with  various  potential  partners  at  reasonable  cost. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 
^Simultaneous  investigation  of  many  possibilities 

^Scours  new,  even  unconventional  markets  utilizing  novel  analytical  techniques 
^Electronic  opportunity  search  for  possible  solutions  to  current  needs  or  prob¬ 
lems  that  could  lead  to  new  products 
^Use  stakeholders  to  identify  possible  leads 

4.2.2  Process  Category  2:  Partner  Selection 

IComponents  in  the  model  which  address  how  the  need  for  partners  is  identified  and  specific  candidates  are 
evaluated.) 

The  category  generally  addresses  the  selection  of  partners.  Type  2  &  4  AVEs  as¬ 
sume  that  the  partnerships  pre-exist,  so  they  will  largely  omit  this  categoiy.  The 
others  may  choose  to  perform  these  actions  in  parallel  with  the  opportunity  iden¬ 
tification  and  crystallization  because  it  could  reduce  the  costs  associated  with  the 
strategy  and  improve  the  relationship  with  the  potential  customer.  But  nominally 
the  business  decisions  will  be  first  associated  with  identifying  an  opportunity,  then 
a  partnership  team. 

Type  1  partners  are  envisioned  more  as  partners,  compared  with  Type  3  rela¬ 
tionships,  which  may  resemble  traditional  supplier  relationships.  It  Is  currently  de¬ 
batable  how  distinct  these  two  types  of  relationships  are  in  the  AVE  context. 

As  with  Category  1 ,  an  AVE  will  be  promiscuous,  forming  and  dissolving  many 
partnerships  among  a  large  portfolio  at  low  cost.  The  partnerships  will  have  loose 
coupling,  being  limited  only  to  the  need  to  address  the  opportunity  well.  This 
might  be  accomplished  by  having  each  partner  tend  to  be  self-organizing  In  the 
context  of  the  Virtual  Enterprise.  And  it  may  be  aided  by  some  partners’  migration 
of  organization-building  tools  from  prior  AVEs. 

4.2.2. 1  Partner  Qualification 

As  noted  in  Opportunity  ID:  Opportunity  Strategy,  there  will  be  a  strategy  which 
can  be  commonly  shared,  and  which  has  a  standard  method  for  defining  core  com¬ 
petencies.  Also,  the  core  competencies  required  by  the  opportunity  will  have  been 
identified.  This  process  concerns  revealing,  with  a  high  level  of  confidence,  the 
core  competencies  of  candidates,  together  with  other  key  business  indicators. 
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A  method  is  required  for  applying  the  competency  definitions  to  partners.  Prob¬ 
lems  could  arise  due  to  dishonestly  and  variations  in  the  definitions.  While  core 
competency  evaluation  must  be  determined,  there  are  other  factors  to  qualify: 
such  issues  as  quality,  technical,  capacity,  and  financial  criteria.  These  criteria  will 
be  evaluated  somewhat  differently  in  an  AVE  context  than  in  a  traditional  context. 
There  needs  to  be  a  quick,  cheap  method  of  getting  this  information  with  suffi¬ 
cient  fidelity. 

There  may  be  methods  for  prequalifying  partners,  one  of  them  being  the  reli¬ 
ance  of  a  third  party  to  precertify  them.  A  question  oHiability  arises  from  mistakes 
or  misrepresentations  made  during  this  process.  There  must  be  a  process  to  ad¬ 
dress  this  issue  of  accountability. 

Overall,  there  will  be  available  a  class  of  metrics  which  address  the  ability  of  a 
firm  to  enter  into  an  AVE,  independent  of  the  value  its  competencies  bring  to  the 
AVE.  (The  ability  to  form  quickly,  flexibly.) 

There  will  be  an  independent  class  of  metrics  associated  with  the  level  of  agility 
the  firm  will  bring  to  the  AVE  during  its  life,  the  ability  to  support  agility  in  the  AVE, 
external  to  the  firm. 

There  may  also  be  a  third  class  of  relatively  independent  metric  which  measures 
the  agility  within  the  internal  operations  of  the  firm,  the  agility  in  own  processes. 

If  there  are  no  qualified  partners,  or  if  an  unqualified  partner  must  be  included 
for  some  reason,  then  there  must  be  a  provision  to  make  that  partner  qualified. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Evaluate  factors  such  as  quality,  technical,  capacity,  financial  criteria,  etc.;  must 
be  done  quickly  and  cheaply  yet  maintain  sufficient  fidelity 
^Provision  to  make  a  potential  unqualified  partner  qualified 
^Minimum  requirements  (information  system,  communications,  resources,  etc.) 
identified  as:  existing;  needed;  not  needed 

4.2.2.2  Partner  Performance  History 

A  key  issue  in  forming  AVEs  is  the  matter  of  trust.  This  collection  of  processes 
facilitates  trust.  A  method  is  required  to  reveal  a  partner’s  history  based  on  proven 
quality,  delivery,  and  other  criteria.  A  related  method  is  required  to  determine 
which  of  the  traditional  and  new  measures  of  a  firm’s  history  is  cogent  to  the  AVE. 
There  could  be  a  single  AVE  profile,  or  this  could  be  situational. 

This  subcategory  is  differentiated  from  the  previous  one  by  focusing  in  on  spe¬ 
cific,  historic  information.  The  previous  category  spans  many  strategies  for  quali¬ 
fication.  This  one  is  concerned  with  data  from  the  past.  Special  analytical  tools  will 
be  required  to  map  past  situations  to  the  current  one  since  it  is  presumed  that  the 
situations  will  widely  differ. 

*  One  agile  strategy  will  be  the  sharing,  possibly  selling,  of  information  among 
current  and  past  AVEs.  Historic  information  may  be  a  sustained  asset  of  dissolved 
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AVEs,  or  there  may  be  a  new  infrastructure.  Generally,  the  issues  are  the  same  as 
with  the  prior  subcategory. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Has  trust  been  demonstrated?  i.e.  proven  quality,  delivery,  ability  to  deal  with/ 
operate,  to  share  share/sell  information  without  violation  of  trust,  etc. 

^Ability  to  apply/map  past  performance  to  new  situations  (look  at  historical  data 

-  safety,  strikes,  performance  responsiveness) 

^History  of  face  to  face  handshake  (informal)  agreements  being  trustworthy. 

^Is  the  potential  partner  able  to  form  and  dissolve  many  partnerships  at  low  cost 

-  relative  to  input? 

4.2.2.3  Partner  Search 

The  two  processes  noted  above  presume  that  some  candidates  have  been  eval¬ 
uated.  But  it  is  likely  that  a  more  exhaustive  search  for  candidates  will  be  desirable. 

It  is  advantageous  to  have  multiple  methods  for  searching  for  candidates.  It  is 
an  open  issue  what  are  the  best  search  criteria  or  search  forums.  It  is  debatable 
whether  a  firms’  self-presentation  will  reflect  the  appropriate  criteria.  In  other 
words,  it  is  unknown  whether  widespread  AVE  formation  depends  on  a  not-yet-de- 
veloped  search  infrastructure. 

An  agile  lead  will  have  strategies  to  search  out  many  potential  partners.  Poten¬ 
tial  AVE  partners  will  be  agile  by  making  themselves  easy  to  be  found  and  evaluat¬ 
ed. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

i  Initiator  should  look  both  internal  and  external  to  the  walls  of  company  -  out¬ 
side  the  box  thinking 

4 Multiple  methods/technologies  (intelligent  agents,  brokers,  etc.)  for  searching 

4.2.3  Process  Category  3:  Formation  (Business  Case  Development  and 
Commitment) 

(Here  we  describe  how  this  part  of  the  model  supports  various  decisions  concerned  with  the  formation  of  the 
virtual  enterprise.) 

Having  identified  the  opportunity  and  partners,  the  AVE  must  fiilly  build  the  de¬ 
tailed  business  case,  make  the  multiple  commitments  required,  and  form  the  AVE. 
There  are  a  substantial  number  of  issues  concerned  with  this  process.  To  a  large 
extent,  everything  until  this  point  has  been  performed  with  the  purpose  of  build¬ 
ing  the  business  case  and  making  the  commitment.  It  is  at  this  point  that  major 
resources  are  committed. 

^  But  it  is  also  true  that  the  AVE  (in  all  its  infrastructure)  must  be  carefully  estab¬ 
lished  in  ways  to  insure  success  in  the  future  phases  (operation  and  dissolution). 
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The  key  to  agility  in  the  Virtual  Enterprise  is  in  this  category.  An  AVE  will,  in  ad¬ 
dressing  the  formation  process,  exhibit  several  agile  attributes.  The  most  notable 
are:  Reusability  (in  infrastructure  components  from  prior  AVEs);  Scalability  (in  es¬ 
calating  core  competencies  of  partners  to  the  AVE  as  a  whole);  Self  Organizing  (in 
distributing  the  binding  infrastructure  among  the  partners);  and  Loose  Coupling 
(by  lowering  the  cost  of  removing  partners  as  conditions  change). 

4.2.3. 1  Vision/Strategy  Development 

The  AVE  has  to  be  founded  on  an  explicit  statement  of  purpose.  This  can  be  built 
on  the  foundation  of  the  strategy  noted  above  in  Opportunity  ID:  Opportunity 
Strategy.  The  strategy  is  likely  to  be  mission-based  and  differ  from  the  host  orga¬ 
nization’s  strategy  in  being  based  on  partially  temporary  infrastructure.  The  strat¬ 
egy  must  incorporate  a  sense  of  the  life-span  of  the  AVE,  how  it  is  going  to  change 
in  response  to  expected  conditions,  and  how  it  is  going  to  institute  agile  practices 
for  unanticipated  change. 

A  particular  AVE  will  have  to  accommodate  new  types  of  agile  practices,  not 
needed  in  each  host  organization. 

The  vision  will  have  been  presented  as  an  early  template  for  determining  the 
feasibility  of  the  specific  AVE.  Wliile  more  detailed  decisions  related  to  formation 
are  noted  below,  they  should  all  relate  to  this  vision.  Unanticipated  events/condi¬ 
tions  may  change  some  of  those  implementation  details,  so  this  vision  is  needed 
as  the  constant  core.  Included  in  the  vision  are  some  basic  principles  about  the 
overall  goals  and  roles. 

Agility  will  be  seen  in  how  readily  and  robustly  the  vision  can  be  developed  and 
shared  among  the  partners. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Explicit  statement  of  purpose;  built  on  the  opportunity  strategy;  mission-based 
modified  strategic  plan; 

^Incorporate  a  sense  of  the  life-span  of  the  AVE 

^Agreement  on  how  to  handle  both  anticipated  and  unanticipated  change 
including  continual  competition  assessment 
^Continual  customer  assessment  (new  &  old) 

^The  customer  will  have  a  role  in  the  AVE  ownership 

^A  common  set  of  ethical  standards  (Code  of  Ethics)  not  legally  binding,  which  is 
an  expression  of  values  which  facilitate  an  environment  of  trust  and  cooperation 

4.2.3.2  Partner  Criteria  and  Selection 

The  subcategory’s  process  is  the  actual  selection  of  and  commitment  to  part- 
iners.  In  an  ideal  case,  it  should  fall  out  of  the  processes  that  precede  it.  However, 
it  is  possible  that  things  will  not  have  proceeded  in  an  orderly,  slow  fashion  to  this 
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point.  So  there  need  to  be  a  collection  of  catch-up  processes  of  filling  in  the  gaps 
and  clarifying  all  the  roles. 

This  process  is  based  on  the  go/no  go  decision  and  involves  implementation  de¬ 
tails  about  the  relevant  infrastructures. 

Agility  will  be  seen  In  how  quickly  resources  can  be  committed  to  close  the  part¬ 
nerships  with  specific  candidates.  The  commitment  will  be  dependent  on  the  agil¬ 
ity  exhibited  in  Category  2:  Partner  Selection. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Core  competency  tradeoffs  among  AVE  members  for  time  and  cost 

4Go/no  go  decision  shared  quickly  throughout  the  initiating  organization  and 
partners 

4.2.3.3  Enterprise  Metrics 

Part  of  the  formation  process  is  in  determining  the  metrics  to  be  applied  across 
the  AVE.  These  will  be  based  on  traditional  financial  and  operational  metrics.  They 
should  be  capable  of  Identifying  change  downstream.  That  is,  they  should  be  capa¬ 
ble  of  determining  not  only  whether  goals  are  being  met,  but  also  to  anticipate 
problems/changes.  Certainly,  there  are  overlaps  between  these  metrics  and  the 
agility  metrics  noted  in  Partner  ID:  Partner  Qualification.  One  can  be  conceived  as 
a  subset  of  the  other. 

Note  that  the  metrics  of  this  subcategory  are  not  the  more  general  set  of  metrics 
addressed  by  our  metrics  project.  Instead,  these  metrics  deal  only  with  the  rela¬ 
tionships  and  interactions  which  need  to  be  addressed  in  forming  the  AVE  by  inte¬ 
grating  processes  from  diverse  sources. 

Agility  will  be  exhibited  not  in  the  acceptance  of  these  metrics,  but  in  their  facile 
use. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 
^Consistent  roll-up  of  heterogeneous  metrics  across  the  AVE 
^Capable  of  Identifying  change  downstream 
^Anticipatory  in  nature 

4.2.3.4  Capitalization 

This  process  deals  with  the  detailed  determination  of  who  commits  what  capital 
(and  other  assets)  and  with  the  commitment  of  those  assets.  It  means  that  new  fi¬ 
nancial/legal  infrastructure  must  be  created.  Where  intellectual  property  is  in¬ 
volved,  this  needs  to  be  evaluated  as  a  contribution.  It  will  be  necessaiy  to  set  the 
method  by  which  the  value  of  intellectual  property  (and  other  dynamic  assets)  is 
determined  as  the  AVE  is  operated  and  the  value  changes. 

As  with  most  of  the  allied  subcategories,  agility  will  be  seen  In  how  quickly, 
competently,  and  cheaply  the  processes  are  conducted. 
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Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Better,  faster,  cheaper  financial/legal  infrastructure 
^Dynamic  assets  -  recognition  that  value  may  change 

4.23.5  Product  Liabilities 

This  process  deals  with  assignment  of  all  anticipated  liabilities,  including  those 
which  are  improbable.  This  process  also  creates  new  legal  infrastructure,  which  is 
related  to  that  noted  above.  Included  in  the  process  is  the  scoping  of  warranties: 
who  is  responsible  for  what  and  how  the  warranty  profile  is  presented  to  the  cus¬ 
tomer.  Note  that  there  is  a  separate  class  of  liabilities  associated  with  the  process 
(ecological  or  social  suits  for  example)  which  are  not  bound  to  the  product.  These 
are  addressed  elsewhere. 

Agility  will  be  exhibited  in  the  legal  infrastructure.  Speed  and  cost  are  not  issues 
here;  instead,  the  problems  concern  accurate  anticipation. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Assigned  responsibility  for  anticipated  liabilities 

^Accurate  anticipation  for  all  potential  liabilities  is  the  key  -  not  speed  and  cost 
4. 2.3.6  Risk/Reward  Strategies 

The  previous  two  processes  are  related  to  contracted  commitment.  This  process 
focuses  on  determining  rewards  in  detail.  Presumably,  risks  and  rewards  will  be  co¬ 
defined,  with  reward  based  on  risk;  risk  is  one  of  the  metrics  which  must  be  cap¬ 
tured  in  the  subcategory  on  metrics  which  follows  contribution,  see  Formation: 
Enterprise  Metrics.  Those  metrics  should  be  capable  of  identifying  failure  modes 
as  a  way  of  assessing  negative  reward. 

The  process  should  accommodate  the  reality  that  the  risk  contribution  may  not 
be  naturally  reflected  in  a  dollar  amount.  Examples  are:  name,  image,  goodwill, 
and  market  intelligence.  Included  in  the  risk  metric  should  be  a  threshold  at  which 
the  dissolve/reconfigure  processes  of  Category  5:  Reconfiguration  and  Dissolution 
are  triggered. 

In  addition  to  the  speed,  correctness  and  cost  issues  normal  to  Category  3:  For¬ 
mation,  agility  in  an  AVE  will  be  improved  if  the  risk/reward  structure  is  itself  agile, 
capable  of  responding  to  change. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Establish  an  atmosphere  that  all  are  viable  value-add  members  of  the  business 
winter  and  intra  dependency/results 

^4.2.3.7  Operating  Structure 

The  processes  of  this  subcategory  address  the  creation  of  the  operational  infra¬ 
structure  to  be  used  in  the  AVE.  Infrastructures  need  to  be  createa  to  support  the 
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relationships  which  partners  have  with  one  another.  Reporting  and  supervisory  re¬ 
lationships  need  to  be  established.  The  hierarchy  of  partners  needs  to  be  explicit. 
How  top  management  spots  are  filled  and  possibly  with  whom  need  to  be  deter¬ 
mined.  It  may  be  that  a  role  unique  to  AVEs  needs  to  be  established:  that  of  score- 
keeper/adjudicator.  This  role  may  be  supplemented  by  processes  which  anticipate 
and  neutralize  conflict,  possibly  through  team-building  activities. 

An  AVE  will  be  agile  in  its  formation  if  both  the  aggregate  and  components  of 
the  partnership  can  bring  the  operating  structure  up  quickly  and  cheaply.  The  re¬ 
sulting  AVE  will  be  agile  in  operation  if  the  partnership  has  been  designed  with 
agility  in  mind.  As  a  result,  this  subcategory  provides  the  bridge  between  agile  for¬ 
mation  and  agile  operation. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Permits  intra-AVE  member  learning,  leadership,  team  building,  brain  storming, 
empowerment,  etc. 

^Minimum  corporate  leadership,  maximum  AVE  teams  cooperation;  P&L  respon¬ 
sibilities  at  the  team  level  within  member  companies 
^Potential  scorekeeper/adjudicator  established 

4.2.3.8  Dissolution  Plan 

AVEs  (certainly  Types  1  and  3)  are  presumed  to  be  temporary,  based  on  a  spe¬ 
cific  opportunity.  Therefore  a  dissolution  plan  must  be  devised,  and  the  infrastruc¬ 
ture  for  dissolution  build  into  the  AVE  when  it  is  created.  As  one  necessary 
component,  a  trigger  or  threshold  needs  to  be  set  to  establish  when  the  opportu¬ 
nity  of  the  occasion  for  the  AVE  ceases  to  be  productively  addressed. 

As  mentioned  in  the  introduction,  a  Virtual  Enterprise  must  have  this  plan  in  or¬ 
der  to  be  agile.  The  best  practice  expected  will  be  in  an  AVE  which  has  clearly 
thought  out  the  plan  and  contingencies  above  and  beyond  a  simple  intent  to  dis¬ 
solve. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^  Built  into  the  creation  of  the  AVE 

^Trigger/threshold  established  for  Dissolution/Reconfiguration:  Identification  of 
Need 

4.2.4  Process  Category  4:  Operation 

[The  model  supports  processes  involved  in  operating  the  virtual  enterprise.] 

Having  established  the  AVE,  it  must  be  operated.  It  should  look  like  a  single  or¬ 
ganization  from  the  outside.  That  Is,  the  operation  should  have  an  external  view 
which  looks  like  a  conventional  organization.  But  there  are  likely  to  be  operational 
(factors  unique  to  the  AVE.  These  may  be  similar  or  identical  to  operation  of  a  large, 
decentralized  manufacturing  operation  (as  in  automobile  or  large  aircraft  enter¬ 
prises). 
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4.2.4. 1  Performance  Measures 

This  collection  of  processes  will  implement  metrics  which  measure  individual 
components  at  the  micro  level,  the  lowest  level  at  which  the  strategy  of  the  AVE  is 
concerned.  But  these  should  combine  at  macro  levels:  one  of  which  are  the  enter¬ 
prise  metrics  of  Operation:  Capitalization.  Therefore,  these  metrics  support  the 
predetermined  risk/reward  structure.  Some  AVEs  may  integrate  processes  to  the 
extent  that  boundaries  between  firms  are  blurred.  In  this  case,  the  AVE’s  perfor¬ 
mance  measures  take  on  the  additional  responsibilities  of  managing  work  normal¬ 
ly  the  purview  of  a  member  firm. 

Agility  in  operation  can  occur  only  if  managers  can  understand  what  is  happen¬ 
ing  both  within  the  AVE  and  within  its  context.  A  best  practice  would  have  in  place 
sufficiently  clear  metrics  to  enable  the  manager  both  to  understand  and  to  control 
dynamic  conditions. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Responsive  to  dynamic  conditions  which  require  real-time  or  near  real-time  per¬ 
formance  measures 

^Federated  metrics 

^Delineation  of  AVE  member  boundaries  required  to  identify  bottlenecks, 
delays,  etc.  in  order  to  maintain  accountability 

4. 2.4.2  Customer  Relations 

The  AVE  must  appear  as  a  unified  organization  to  the  customer,  so  processes 
must  be  established  to  support  this  transparency.  Presumably,  some  of  the  risk/re¬ 
ward  structure  will  be  based  on  customer  satisfaction.  This  necessitates  a  metric 
which  measures  satisfaction  and  assigns  traceability  to  the  proper  component. 
Processes  have  to  recognize  and  ideally  to  measure  intangibles  such  as  goodwill. 
Also  desirable  are  processes  which  support  giving  back  to  the  community,  society, 
and  environment. 

Conventional  agility  is  supported  in  an  AVE  which  has  agility  in  this  respect.  By 
being  in  touch  with  the  customer,  presumably  by  their  membership  in  the  AVE, 
market  changes  can  be  better  anticipated  and  understood. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Processes  to  support  transparency  of  the  AVE;  looks  like  one  entity  to  customer 
^Metric  to  measure  customer  satisfaction  in  order  to  assign  within  the  risk/ 
reward  structure 

4.2.4.3  Operating  Practice 

^  Once  the  AVE  is  up  and  running,  in  important  ways  it  should  function  as  if  it 
were  a  single  organization.  Boundaries  between  firms  will  be  minimized,  so  the 
processes  used  in  some  types  of  AVEs  will  be  managing  certain  processes  within 
the  AVE’s  components  instead  of  merely  administering  boundaries  between  firms. 


February  IS,  1997 


67 


Part  1 .  Metrics  Handbook 


This  subcategory  is  intended  to  incorporate  ail  the  Best  Agile  Practices  from  other 
studies  relating  to  agility  in  a  single  corporation.  However,  there  may  be  additional 
practices  unique  to  the  AVE. 

All  of  the  Best  Agile  Practices  associated  with  the  agile  operation  of  an  enter¬ 
prise  are  incorporated  here  by  reference. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Integrated  processes  across  the  AVE’s  components  to  maximize  process  syn¬ 
chronization 

^Ingrain  with  continuing  the  virtual  thinking  at  all  levels  of  the  AVE 
^Scalable,  reconfigurable,  reusable 

4.2.5  Process  Category  5:  Reconfiguration  and  Dissolution 

|The  model  supports  processes  associated  with  the  end  of  the  virtual  enterprise  and  its  possible  recycling.) 

At  a  predetermined  point,  the  time  will  come  when  the  opportunity  has  been 
fully  satisfied  or  otherwise  changes.  It  will  then  be  time  to  dissolve  or  radically  re¬ 
form  the  AVE.  This  point  is  presumed  to  be  mutually  understood  within  the  AVE, 
and  may  be  tracked  by  a  metric. 

Moreover,  that  point  probably  is  well  outside  the  normally  encountered  dyna¬ 
mism  addressed  by  agility  practices  of  the  previous  category.  However,  reconfigu¬ 
ration  may  be  a  normal  agile  response  in  some  types,  for  example  Type  3,  Agile 
Supplier  Chains.  If  the  AVE  is  to  be  reformulated,  this  process  will  feed  back  to  the 
first  category. 

It  appears  clear  that  agility  here  cannot  be  created;  it  has  to  be  inherited  from 
earlier  processes  as  described  above,  particularly  in  Operation:  Dissolution  Plan. 

4.2.5. 1  Identification  of  Need 

The  AVE  will  have  predefined  sunset  conditions  related  to  the  situation  of  the  ini¬ 
tiating  opportunity.  A  process  is  needed  for  monitoring  those  sunset  conditions, 
with  special  metrics  in  some  cases,  to  identify  when  the  formation  of  the  AVE 
needs  to  be  revisited.  This  process  will  trigger  (and  provide  information  for)  fun¬ 
damental  change  of  both  the  nature  and  the  structure  of  the  AVE. 

Once  again,  agility  is  tied  to  metrics.  The  metrics  central  to  this  process  derive 
from  the  environment,  see  Opportunity  ID:  Opportunity,  Strategy  and  Operation: 
Customer  Relations  and  the  predetermined  plan  (see  Formation:  Vision/Strategy 
Development,  Formation:  Partner  Criteria  and  Selection,  and  Operation:  Perfor¬ 
mance  Measures. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Revalidate  assumptions  of  pre-defined,  mutually  understood  criteria  for  dissolu- 
'  tion  or  radical  reformation 

^  Human  decision  maker  is  supported  by  intelligent  decision  aides  coupled  to 
trigger  matrixes 
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4.2.5.2  Residual  Liabilities 

Whether  dissolved  or  reconstituted,  there  needs  to  be  a  set  of  processes  to 
identify  and  assign  responsibility  for  residual  liabilities.  Examples  would  include 
warranties,  environmental  concerns,  employee  benefits,  and  product  liabilities. 
Note  that  even  normal  operations  or  changes  in  the  AVE  may  require  liability  reas- 
possible  that  the  assignee  might  not  have  been  a  partner  in  the 
AVE.  It  may  instead  be  a  partner  acting  in  a  new  role,  or  it  may  be  one  or  more 
successor  AVEs. 

As  with  all  issues  in  this  category,  the  agility  will  have  already  been  built  in  by 
this  time,  in  the  legal  and  social  infrastructure. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Validate  assumptions  and  execute  pre-determined  processes  to  identify  and 
assign  responsibility  for  residual  liabilities  based  on  current  opportunity.  This 
process  may  require  a  total  rethink  of  the  original  plan. 

^Assignee  may  not  have  been  partner  in  the  AVE  (may  be  partner  acting  in  new 
role,  may  be  one  or  more  successor  AVE’s) 

4.2.5.3  Asset/Equity  Dispersal 

A  series  of  processes  are  required  to  distribute  assets  and  equities.  This  is  sim¬ 
ilar  to  the  liability  assignment.  But  whereas  liabilities  are  not  precisely  quantifi¬ 
able,  assets  and  equity  should  be  more  so.  So  the  processes  are  likely  to  be  more 
metrics-based,  cost-based.  However,  assets  could  also  include  intangibles  such  as 
goodwill.  This  subcategory  does  not  include  profits  dispersal,  since  that  should 
have  been  handled  in  normal  operation. 

Moreover,  assets  form  the  basis  for  reconfiguring  or  otherwise  reconstituting 
the  AVE. 

This  subcategory,  as  with  the  preceding  one,  will  be  addressed  by  previously  de¬ 
termined  agile  mechanisms.  However,  both  need  themselves  to  be  agile  to  re¬ 
spond  to  unexpected  conditions  in  the  dissolution,  for  example  catastrophic 
failure. 

Example  attributes  of  this  process  that  would  make  it  agile  would  be: 

^Validate  and  execute  pre-determined  process  of  dispersal 

^Dispute  resolution,  if  necessary,  (mediation,  arbitration,  court  system,  etc.) 

^Metrics  or  cost  based 

4.2.6  Infrastructure  Elements 

[Another  dimension  of  the  model  are  the  infrastructures.  They  are  all  described  here.) 

I  Infrastructure  forms  the  second  axis  or  dimension  of  the  model.  The  idea  in  this 
breakdown  is  to  separate  the  different  dynamics  that  bind  the  AVE  together.  In 
agility  considerations,  we  focus  on  the  coupling  of  different  entities  in  the  enter- 
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prise.  The  laws  and  behavior  of  workflow  differ  fundamentally  from  those  of,  say 
work  safety  regulations,  so  we  strive  to  make  the  differences  clear  in  the  model. 

Unfortunately,  some  of  the  terms  we  use  for  these  infrastructures  are  also  used 
in  work  by  others  to  mean  different  things.  There  doesn't  seem  to  be  any  way 
around  this,  since  ail  the  useful  words  have  been  overloaded.  So  careful  definitions 
must  suffice. 

4.2.6. 1  Information  Infrastructure 

Information  Infrastructure  is  a  fundamental  infrastructure  dealing  with  the  na¬ 
ture  of  communication.  This  is  not  to  be  confused  with  the  arrangements  for  au¬ 
tomated  support  for  the  other  infrastructures.  Automated  support  is  implicitly  in 
the  other  categories;  for  instance  computerized  workflow  support  such  as  model¬ 
ing  and  operating  control  systems  are  considered  components  in  the  Legal/Explicit 
Infrastructure:  Workflow  area. 

This  infrastructure  deals  with  the  underlying  means  for  communication  and  co¬ 
ordination,  and  includes  verbal,  written  and  graphical  notations  and  the  logics  and 
abstractions  which  underlay  them.  The  project  has  some  results  in  notations,  and 
information-theoretic  (meaning  situation-theoretic)  approaches  to  describe  and 
partially  understand  the  mechanics  here.  Since  these  are  not  engineerable  at  the 
VE  level  for  the  individual  enterprise,  we  ordinarily  do  not  include  this  infrastruc¬ 
ture. 

The  addition  of  metrics  to  the  disciplines  of  enterprise  engineering  and  opera¬ 
tion  is  at  this  level. 

4.2.6.2  Social/Cultural  Infrastructure 

The  infrastructures  below  deal  with  dynamics  in  the  enterprise  which  is  implicit 
while  the  two  below  are  defined  explicitly;  elsewhere  we  call  this  the  soft  infra¬ 
structure  where  the  others  are  hard. 

4Social  and  Psychological  Laws 

This  subinfrastructure  concerns  behavior  that  seems  to  be  hard-wired:  certain 
personality  types,  interactions,  and  reproducible  group  dynamics.  Some  enter¬ 
prise  engineering  can  be  accomplished  here,  but  the  understanding  of  the  laws  at 
work  is  relatively  crude.  Engineering  often  consists  wholly  of  the  evaluation  and 
selection  of  individuals  and  teams  that  work. 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be:  AVE 
leadership  is  attentive  to  and  leverages  basic  patterns  of  human  behavior,  group 
dynamics,  and  individual/team  motivation. 

4Community  Cultures 

Community  Culture  subinfrastructure  deals  with  influence  and  communication 
networks  and  associations  which  are  driven  by  identification  with  faaors  such  as 
naUonality,  ethnicity,  race,  and  gender.  Many  other  identities  are  involved:  club, 
religious,  class,  political  and  trade  affiliations  are  only  examples. 
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Example  attributes  of  this  infrastructure  that  would  make  It  agile  would  be- 
methods  for  readily  tailoring  processes,  contracts  and  workflow  to  leverage  spe- 
cial  (^Itural  strengths  and  weaknesses  (e.g.  Korean  vs.  Mexican  autoworker 

schedules  ;  method  to  proactively  identify  potential  work  flow  descriptions  due 
to  cultural  differences. 

4Business  Culture 

Business  Culture  is  a  special  kind  of  community  culture  that  may  cut  across  (or 
federate)  many  communities.  It  is  unique  in  being  sustained,  possibly  consciously 
generated,  by  the  enterprise.  ^ 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be:  syn¬ 
ergism  of  business  processes  leveraging  the  diversity  of  business  culture  (allows 
heterogeneous  cultures  in  the  AVE). 


4.2.6.3  Legal/Explicit  Infrastructure 


The  infrastructure  is  defined  by  processes  that  are  explicit  and  possibly  engi¬ 
neered  m  the  enterprise.  Explicit  means  that  they  are  articulated  somewhere.  It  in¬ 
cludes  processes  that  deal  with  how  the  business  is  run,  who  manages  whom  and 
who  mal^s  what  decisions.  The  rules  that  influence  job  descriptions  are  included. 
In  the  virtual  enterprise,  this  concerns  who  does  what  in  supporting  interactions. 

EBusiness  Processes 


The  sub-infrastructure,  Business  Processes  means  that  the  processes  deal  with 
such  things  as  the  risk/reward  system,  the  supervisory  and  monitoring  relation- 
ships  and  ownership  of  various  elements  of  the  enterprise. 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be:  dis¬ 
tributed  ownership  of  the  strategic  planning  process,  including  spread  into  the 
customer  base;  distributed  responsibility  for  customer  relations  and  modeling 
expectations;  flexibility  in  how  the  monitoring  for  rewards  is  handled;  ability  to 
recognize  and  leverage  risk  by  a  partner  when  the  reward  is  AVE-wide;  ability  to 
reconfigure  supervision  of  product/service  quality/completion;  ability  to  redis¬ 
tribute  who  does  what  and  when  in  terms  of  actual  value-added;  support  system 
for  innovation  is  established  and  In  place 

A  more  specific  breakdown  can  be  made.  At  this  level,  we  find  that  the  details 
vary  according  to  different  business  models  and  market  sectors. 

4Strategy  Development:  concerns  the  conventional  business  strategy  that 
would  for  instance  be  in  a  business  plan,  concerning  specific  approaches 
to  markets,  competition,  partners,  etc.  A  key  component  of  this 
infrastructure  is  who  owns/can  adapt  the  strategy. 

4Supervise  Risk/Reward  Process:  addresses  the  explicit  plans  for  who  gets 
paid  how  much  for  what.  A  key  factor  Is  who  owns/can  change  the  risk/ 
reward  process. 

4Supervise  Engineering  Quality:  deals  with  who  owns/can  change  the 
processes  which  match  customer  demands  for  quality  with  the  VE’s 
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processes,  and  what  the  processes  are  to  provide  that  supervision. 

4Work  Scheduling:  who  decides  and  can  change  who  does  what  vsathin 
the  VE. 

4Depth  of  Customer  Relations:  address  who  is  and  what  processes  are 
responsible  for  understanding,  dealing  with,  and  satisfying  the  customer. 
Includes  the  processes  to  change  the  customer  and  how  they  are  dealt 
with. 

^  Legal/Regulatory 

The  sub-infrastructure,  of  Legal/Regulatory  concerns  the  processes  that  deal 
with  legal  instruments.  Internally,  these  would  be  contract  clauses;  externally, 
they  would  be  codes,  laws,  and  regulations. 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be:  the 
ability  to  simultaneously  manage  different  models  of  culture;  use  of  contract  tem¬ 
plates  based  on  case  law  and  other  precedents;  a  proliferation  of  agents  to  fill 
legal  needs  of  discovery,  certification,  and  indemnification;  flexibility  in  how  con¬ 
tracts  support  fluid,  and  flexibly  scoped  (e.g.  partner  vs.  AVE)  risk/reward  scenar¬ 
ios;  flexibility  in  who  is  the  customer  (e.g,  licensing  by  Disney  moving  from  films 
to  tapes,  parks,  toys,  etc,);  flexibility  for  how  intellectual  property  is  managed 
during  and  after  the  activity  of  the  AVE;  pre-determined,  pre-prioritized  dispute 
resolution  processes. 

A  more  specific  breakdown: 

4  Quality  Assurance  Agreements:  This  specific  set  of  contracts  and 
regulations  concerns  responsibilities  and  processes  involved  with 
measuring,  monitoring  and  guaranteeing  the  quality  of  each  partner’s 
effort  in  the  context  of  the  VE. 

4Risk/Reward  Contracts:  This  specific  set  of  contracts  and  regulations 
concerns  responsibilities  and  processes  associated  with  how  each  member 
gets  reimbursed  (or  receives  other  benefit)  for  benefiting  the  VE.  Naturally, 
penalties  for  harming  the  VE  are  included. 

4How  VE  is  Represented:  This  specific  set  of  contracts  and  regulations 
concerns  responsibilities  and  processes  that  support  how  each  member 
contributes  to  the  relationship  with  the  customer. 

4  Assignment  of  New  Technology:  This  specific  set  of  contracts  and 
regulations  concerns  how  new  intellectual  property  gets  developed,  used 
in  the  VE  and  used  outside  the  context  of  the  VE. 

4  Labor  Agreements:  This  specific  set  of  contracts  and  regulations  concerns 
how  the  VE  deals  with  workforce  issues  that  are  normally  covered  in 
continuing  institutions:  pensions,  insurance,  continuing  education  for 
examples. 

^WorkFlow  (Business  Plan) 

This  sub-infrastructure  includes  processes  that  are  explicitly  defined  to  deter¬ 
mine  the  sequence  of  work.  It  differs  from  Business  Processes;  that  group  deals 
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with  processes  in  the  enterprise  that  affect  product  (or  service);  this  group  deals 
with  processes  associated  with  the  product  that  affect  the  enterprise.  Physical 
Infrastructure:  Warehousing/Logistics  deals  with  physically  determined  proce¬ 
dures/rules;  this  group’s  rules  are  defined  by  business  needs. 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be: 
adaptability  in  who  does  what  and  when  among  existing  and  potential  partners: 
adaptability  in  who  tracks  that  performance:  distributed  responsibility  for  han¬ 
dling  complaints  and  researching  improvements:  a  robust  mechanism  for  han¬ 
dling  exceptions  facilitate  open  communication. 

A  more  detailed  breakdown: 

^Planning  Work  Breakdown  Assignments:  processes  concern  how  the 
work  of  the  VE  is  decomposed  among  the  various  partners  to  the  benefit 
of  both  each  partner  and  the  VE. 

4Work  Breakdown  Responsibilities:  processes  concern  who  is  responsible 
for  what  work  in  the  VE.  The  previous  group  dealt  with  planning,  this 
deals  with  performing. 

4Monitoring/Adjusting  WBS:  processes  concern  who  in  the  VE  is 
responsible  for  monitoring  the  work  distribution  once  the  VE  is  in 
operation,  and  adjusting  the  assignments  as  conditions  change. 

4 Arbitration/Adjudication:  processes  concern  how  complaints  are  handled 
and  controversies  resolved,  presumably  early  in  the  game. 

4Routine  Exception  Handling:  processes  concern  how  unplanned 
exceptions  (other  than  those  involving  reassignment  of  responsibilities) 
are  handled. 

4.2.6.4  Physical  Infrastructure 

This  infrastructure  encompasses  processes  that  are  governed  by  physical  laws. 
^  Warehousing/Logistics 

Subinfrastructure  deals  with  issues  associated  with  the  movement  and  storage  of 
goods,  equipment  and  personnel. 

Example  attributes  of  this  infrastructure  that  would  make  It  agile  would  be:  real¬ 
time  Interoperatable  tracking  system;  location  of  human  and  physical  assets  inde¬ 
pendent  of  ownership  or  paymaster:  high  speed,  low  cost  of  document  move¬ 
ment  for  generation/change  (it's  primarily  a  physical  ownership  and  movement 
problem):  ability  to  sustain  a  high  number  of  opportunistic  meetings  (unplanned 
encounters  and  self-directed  agendas).  This  includes  surrogates  for  physical  col¬ 
location  such  as  electronic  communication;  redundancy  of  facilities  and  network 
creates  lack  of  dependency. 

Deeper  breakdown: 

4  VE  Human  Collaboration:  how  people  gather  and  interact  to  support  the 
VE.  This  includes  surrogates  for  physical  collocation  such  as  electronic 
communication. 
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4VE  Product  Collaboration:  how  various  non-human  resources  of  the  VE 
which  must,  collaborate  as  if  they  were  collocated,  for  example  as  virtual 
workcells. 

^Customer’s  Pipeline.  Product:  how  the  flow  of  components  and  services 
which  constitute  the  product  of  the  VE  is  physically  linked  to  the 
customer. 

^Customer’s  Pipeline.  People:  how  the  individual  persons  in  the  VE 
communicate  with  the  customer. 

4Raw  Commodities:  how  raw  materials  which  feed  the  VE  flow  into  it. 
^Equipment 

Subinfrastructure  deals  with  physical  resources  (including  facilities)  employed  by 
the  VE  to  accomplish  its  goals:  doing  the  work  as  well  as  creating,  sustaining  and 
changing  the  VE.  Agile  processes  within  this  infrastructure  would  be  shared  by  a 
Flexible  Manufacturing  infrastructure  model. 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be:  mod¬ 
ular,  reconfigurable,  flexible,  relocatable,  maintainable,  and  scalable  equipment, 
skill  sets  and  team;  multiple  sources  of  equipment 
More  detail: 

4How  Modular:  equipment  and  related  processes  which  support  common 
and  standard  interfaces  so  that  equipment-related  processes  can  be 
defined  in  an  encapsulated  form  as  objects  or  agents.  This  allows 
reconfiguration  of  collections  of  such  processes. 

4How  Reconfigurable:  equipment  and  related  processes  which  individually 
are  reconfigurable  to  perform  a  range  of  functions. 

^How  Scalable:  equipment  and  related  processes  which  can  support  an 
increase  In  load,  throughput,  or  complexity. 

4How  Relocatable:  equipment  and  related  processes  which  can  be 
relocated  from  one  site,  cell,  or  VE  partner  to  another. 

4How  Storable:  equipment  and  related  processes  which  can  be  easily  and 
cheaply  set  aside  and  recovered  when  needed. 

^Physics 

Subinfrastructure  deals  with  those  processes  that  are  narrowly  constrained  by 
only  some  law  of  physics,  for  example  assembly  sequences,  or  geographic  factors 
that  effect  materials  properties. 

Example  attributes  of  this  infrastructure  that  would  make  it  agile  would  be:  lack 
of  dependency  on  processes  that  cannot  be  scaled  for  physical  or  time  reasons 
(2.5  micron  chips  need  clean  rooms,  epoxy  curing  requires  a  large  autoclave  and  a 
set,  long  curing  time):  lack  of  dependency  on  a  raw  material's  source  (not  paper 
mills,  aluminum  smelting,  raisin  growing):  lack  of  dependency  on  a  customer's 
fixed  location  (not  fire  stations,  congressional  lobbying,  concrete  plants):  lack  of 
dependency  on  physical  presence  to  detect  an  instant,  short-lived  need  (slogan 
tee-shirts  for  demonstrations) 
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Greater  breakdown: 

^Geographically  Limited  Processes:  processes  that  are  tied  to  certain  areas. 
For  instance  ore  smelting  is  limited  to  proximity  to  mines;  aircraft 
servicing  is  limited  to  airports. 

4Scale  Limited  Processes:  processes  that  are  tied  to  certain  physical  scales. 
For  example,  semiconductor  fabrication  is  highly  defined  by  feature  size 
limits;  certain  composite  wing  sections  are  constrained  to  the  size  of 
curing  autoclaves. 

^Attention  Limited  Processes:  processes  which  are  influencable  only  if  you 
are  in  the  right  time  and  place.  Many  market-creation  activities  (promoting 
shoes  at  the  Olympics,  reporting  the  news  are  obvious  examples),  depend 
on  having  alert  agents  when  and  where  it  counts. 

4Time  Limited  Processes:  processes  that  are  tied  to  certain  physical  time 
scales.  For  example:  brewing,  farming,  servicing  life  insurance. 

4 Accident  Limited  Processes:  processes  that  depend  on  unpredictable  (or 
nearly  so)  happenstance.  Examples  might  be  disaster  recovery  services;  or 
fabrication  of  jewelry  using  extremely  rare  gems.  Note:  this  is  a  type  of 
process  that  presumes  a  competence  in  agility. 

4.2.7  Infrastructure  Observations 

[Some  perspectives  on  the  infrastructures  are  noted:  how  they  are  numbered,  some  discussion  on  how  they  can 
to  be  named,  noting  alternatives,  and  internal  dependencies  among  them.] 


4.2.7. 1  Numbering 

In  most  of  the  discussion  above,  weVe  chosen  not  to  include  the  numbering  sys¬ 
tem  because  the  numbering  will  confusingly  conflict  with  paragraph  numbers.  The 
lifecycle  processes  form  rows  in  the  matrix,  the  usual  form  of  the  model.  And  the 
infrastructures  form  columns.  A  standard  numbering  system  that  has  evolved  is  for 
lifecycle  processes: 

4 1 .  Opportunity  Identification 

^1.1  Opportunity  Strategy 

4 1 .2  Exposure 

4 1 .3  Targeted  Marketing 

4 1 .4  Search 

42.  Partner  Selection 

42.1  Partner  Qualification 

42.2  Partner  Performance  History 

42.3  Partner  Search 

43.  Formation 

43.1  Vision/Strategy  Development 

43.2  Partner  Criteria  and  Selection 
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^3.3  Enterprise  Metrics 

43.4  Capitalization 

43.5  Product  Liabilities 

43.6  Risk/Reward  Strategies 

43.7  Operating  Structure 

43.8  Dissolution 

44.  Operation 

44.1  Performance  Measures 

44.2  Customer  Relations 

44.3  Operating  Practice 

45.  Reconfiguration  and  Dissolution 

45.1  Identification  of  Need 

45.2  Residual  Liabilities 

45.3  Asset/Equity  Dispersal 

The  rows  (infrastructures)  use  an  alphabetic  scheme.  The  focus  of  the  metrics 
project  was  on  infrastructures  C  and  D  below,  so  they  have  been  expanded  to  a 
level  appropriate  for  evaluating  an  agility  strategy.  Note  that  at  this  level,  the  three 
digit  level,  the  breakdown  is  domain  dependent.  The  breakdown  here  is  typical  of 
our  case  study,  a  conventional  defense  aerospace  supply  chain. 

4A.  Information  Infrastructure 
4B.  Social/Cultural  Infrastructure 

4B.a  Social  and  Psychological  Laws 
4B.b  Community  Cultures 
4B.C  Business  Culture 
4C.  Legal/Explicit  Infrastructure 

4C.a.a  Business  Processes:  Strategy  Development 
4C.a.b  Business  Processes:  Supervise  Risk/Reward  Process 
4C.a.c  Business  Processes:  Supervise  Engineering  Quality 
4C.a.d  Business  Processes:  Work  Scheduling 
4C.a.e  Business  Processes:  Depth  of  Customer  Relations 
4C.b.a  Legal/Regulatory:  Quality  Assurance  Agreements 
4C.b.b  Legal/Regulatory:  Risk/Reward  Contracts 
4C.b.c  Legal/Regulatory:  How  VE  is  Represented 
4C.b.d  Legal/Regulatory:  Assignment  of  New  Technology 
4C.b.e  Legal/Regulatory:  Labor  Agreements 

4C.c.a  WorkFlow  (Business  Plan):  Planning  Work  Breakdown  Assignments 
4C.c.b  WorkFlow  (Business  Plan):  Work  Braikdown  Responsibilities 
4C.C.C  WorkFlow  (Business  Plan):  Monitoring/Adjusting  WBS 
4C.c.d  WorkFlow  (Business  Plan):  Arbitration/Adjudication 
4C.c.e  WorkFlow  (Business  Plan):  Routine  Exception  Handling 
4D.  Physical  Infrastructure 

4D.a.a  Warehousing/Logistics:  VE  Human  Collaboration 
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^D.a.b  Warehousing/Logistics:  VE  Product  Collaboration 

4D.a.c  Warehousing/Logistics:  Customer’s  Pipeline,  Product 

^D.a.d  Warehousing/Logistics;  Customer’s  Pipeline,  People 

^D.a.e  Warehousing/Logistics:  Raw  Commodities 

^D.b.a  Equipment:  How  Modular 

^D.b.b  Equipment:  How  Scalable 

^D.b.c  Equipment:  How  Reconfigurable 

^D.b.d  Equipment:  How  Relocatable 

^D.b.e  Equipment:  How  Storable 

^D.c.a  Physics:  Geographically  Limited  Processes 

^D.c.b  Physics:  Scale  Limited  Processes 

^D.c.c  Physics:  Attention  Limited  Processes 

^D.c.d  Physics:  Time  Limited  Processes 

4D.c.e  Physics:  Accident  Limited  Processes 

4.2. 7.2  Naming 

The  terms  that  have  been  used  may  possibly  be  confusing  and  misleading.  Legal/ 
Explicit  in  particular  can  give  the  wrong  connotation  to  an  infrastructure  of  rules 
and  policies  which  incidentally  includes  laws.  It  was  proposed  that  these  be  re¬ 
named  to  more  closely  express  the  qualities  that  discriminate  them.  If  those  qual¬ 
ities  are  natural  more  intuitive,  then  the  names  will  make  sense.  In  the  end,  we 
chose  not  to  change  the  names,  but  the  considerations  help  to  define  the  catego¬ 
ries. 

A  proposal  was  made  to  rename  Physical  to  Explicit-Physical.  This  domain  deals 
with  infrastructure  issues  which  are  physically  real,  so  have  unambiguous,  express¬ 
ible  characterizations  which  include  the  laws  of  physics. 

Legal/Explicit,  under  this  proposal,  might  then  become  Explicit-Procedural 
What  characterizes  this  infrastructure  is  the  explicit  expression  of  the  rules,  pro¬ 
cedures,  and  laws  Involved.  It  may  not  be  fair  to  claim  that  this  collection  is  fiilly 
unambiguous,  consistent,  or  internally  correct,  but  it  must  be  expressible.  The  in¬ 
frastructure  may  have  non-deterministic  mechanisms,  whereas  the  physical  mech¬ 
anisms  of  the  above  are  presumed  to  be  deterministic. 

Both  the  cases.  Physical  and  Legal/Explicit,  might  have  some  mechanisms  that 
are  not  controllable  (civil  laws,  physical  laws)  and  some  that  are  (business  rules, 
plant  layout). 

Continuing  the  pattern,  Social/Cultural  appears  as  Implicit.  It’s  assumed  that 
some  of  the  dynamics  at  work  are  hardwired  into  our  genes  and  that  other  dynam¬ 
ics  are  the  result  of  choices  and  learned  behavior.  Thus,  this  infrastructure  catego¬ 
ry  involves  the  balancing  of  these  two  types.  Which  issues  are  natural  and  which 
(artificial,  and  whether  this  should  reflect  the  difference  by  being  two  categories 
instead  of  one,  are  open  issues. 
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It’s  assumed  that  although  the  forces  at  work  are  not  explicit,  their  principles 
can  be  understood  and  codified,  though  perhaps  only  by  induction.  Our  effort  in 
situation  theory  helps  with  understanding  the  implicit  principles. 

This  leaves  the  Information  Infrastructure.  It  has  always  been  unique  in  the  sense 
of  being  the  most  fundamental.  Rather  than  being  the  set  of  computers  in  an  en¬ 
terprise,  this  set  of  mechanisms  deals  with  the  ability  to  represent,  integrate  in 
some  fashion,  and  manage  the  various  representations  involved.  There  are  a  host 
of  issues  that  follow,  but  the  discriminator  from  the  others  is  simple.  They  deal 
with  the  actual  applications,  whereas  this  one  deals  with  the  underlying  represen¬ 
tations. 

So  the  proposal  was  to  replace  the  terms: 

^Physical 
^  Legal/Explicit 
^Social/Cultural,  and 
^Information  Infrastructures, 


with: 


^Explicit-physical 

^Explicit-procedural 


^Implicit,  and 

4  Representational  Infrastructures. 


Ultimately,  we  decided  not  to  make  the  name  changes.  We  would  have  done  so 
if  the  target  audience  were  academics  who  could  appreciate  the  more  precise 
terms.  But  since  the  user  is  the  decisionmaker,  we  felt  that  despite  problems,  any 
intuitive  aid  is  a  plus. 

The  four  infrastructures  may  be  clean  and  distinct  regarding  the  tools  liised  to 
express  and  manipulate  metrics  (that  remains  to  be  seen),  but  they  are  not  distinct 
in  the  way  that  decisions  will  be  made.  In  particular,  the  four  infrastructures  are 
not  in  a  formally  orthogonal,  but  in  a  dependent  relationship.  Fortunately,  the  de¬ 
pendency  seems  to  be  straightforward  and  linear. 


Each  of  the  four  infrastructures  inherits  some  requirements  from  the  preceding 
one  and  some  representational  constraints  from  the  one  following.  That  is,  the 
methods  used  to  represent  information  in  the  more  explicit  ones  build  on  tech¬ 
niques  used  in  the  less  explicit  ones.  So,  for  example,  the  representation  paradigm 
used  in  the  Legal/Explicit  (Explicit-Procedural)  domain  inherits  properties  from 
that  used  in  the  Social/Cultural  (Implicit)  domain. 

This  issue  is  important  because  of  the  implications  for  integrating  and  trans¬ 
porting  information  across  domains.  We’d  like  to  have  our  cake  and  also  eat  it: 
while  recognizing  that  different  representation/application  paradigms  are  a  fact  of 
life,  we’d  also  like  to  work  with  some  principles  that  would  apply  across  the  enter- 
'prise.  The  metrics  should  be  as  simple  as  possible,  leveraging  the  enterprise-wide 
issues  as  much  as  possible. 
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4.2.73  Dependencies 


We  took  the  infrastructure  dependencies  a  step  further,  since  there  are  internal 
dependencies  that  are  generally  recognized.  For  instance.  Business  Culture  often 
affects  Business  Processes.  These  dependencies  are  listed  below  and  shown  in  the 
figures  which  follow.  They  help  in  selecting  the  few  cells  that  are  key  to  an  agility 
strategy. 

^Social/Cultural  Infrastructure 

4Social  and  Psychological  Laws  is  weakly  affected  by  Business  Culture 
4Community  Cultures  are  affected  by  Social  and  Psychological  Laws 
^Business  Culture  is  affected  by  Community  Cultures 
^Legal/Explicit  Infrastructure 

4Business  Processes  are  affected  by  Business  Culture  and  Legal/Regulatory 
4 Legal/Regulatory  is  weakly  affected  by  Social  and  Psychological  Laws 
4  Workflow  is  affected  by  Business  Processes 
4 Physical  Infrastructure 

4Warehousing/Logistics  is  affected  by  Workflow  and  Physical  Laws 
4Equipment  is  affected  by  Workflow,  Warehousing/Logistics  and  Physical 
Laws 

4Physical  Laws  are  not  affected  by  anything 


Figure  4-2:Key  Infrastructure  Breakdowns 
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Social/Cultural 


CultuTT^  ^1® 

^  subsumes  another's, 

in  pairs 

shown  by  arrows 


Legal/Explici 


Physical 


Figure  4-3:Key  Dependencies 


4.2.8  Example  Cells 

(The  Reference  Model  is  further  clarified  by  giving  detailed  examples  of  twenty  cells.  Each  example  has  three 
example  instances.] 
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WeVe  found  that  the  best  way  to  describe  the  AVE  Reference  Model  is  to  sug¬ 
gest  some  examples  for  cells.  WeVe  selected  twenty  example  cells,  which  have 
been  judged  high  value  cells  for  the  defense  aerospace  case. 


CO 

C  tD 


1 ,3  Targeted  Market 

umiiiiiiiiiiii^i 

3.6  Risk/Reward  Strateg  ies  IHHIIHII 
'  4.1  Performance  Metrics 
5.1  Identify  Need  for  Change  |||||||||m||||||||| 


Table  4-1 :  Specific  Cells  of  Interest 

For  each  of  these  cells  we've  given  a  definition  and  provided  three  suggestions. 
Note  that  these  are  not  prescriptive;  what  cells  are  important,  and  what  is  the  most 
agile  entry  in  a  given  cell  is  directly  related  to  strategic  and  environmental  condi¬ 
tions.  And  of  course,  a  certain  type  or  extent  of  agility  may  not  be  beneficial  to  the 
VE. 


4.2.8. 1  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column  C.a.e; 
Legal/Explicit  Infrastructure:  Business  Processes:  Depth  of  Customer  Relations 

Cell  concerns  business  processes  which  support  how  new  markets  are  identi¬ 
fied,  and  existing  markets  are  served  and  extended  through  establishing  strong 
and  meaningful  relationships  with  customers. 

Examples: 

y  4A  business  process  which  sends  sales  and  marketing  staff  on  prospecting  mis¬ 
sions,  customer  visits  to  learn  what  opportunities  are  nascent. 

4VE  marketing  practices  which  encourage  partners  to  bring  market  contacts  to 
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the  VE  even  though  they  are  outside  the  existing  VE  scope. 

^Customer  focus  groups  which  are  convened  with  the  intent  of  exploring  what-if 
scenarios. 

4.2.8.2  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column  C.b.b: 
Legal/Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Contracts 

Cell  concerns  how  partnership  contracts  are  structured  within  the  VE  to  reward 
partners  for  promoting  the  VE  outside  of  their  primary  role,  possibly  penalizing 
partners  In  some  way  for  not  advancing  the  VE  where  It  conflicts  with  their  inter¬ 
ests. 

Examples: 

^Contract  provisions  which  provide  a  finder’s  fee  for  identifying  both  promising 
new  market  targets  and  ones  that  work. 

^Provisions  that  subsidize  partners  to  expand  capabilities  in  such  a  way  that  the 
benefit  accrues  more  to  the  VE  in  new  markets  than  to  the  partner  in  increased 
profits. 

^Provisions  that  withhold  bonus  payments  from  partners  who  siphon  off  new 
opportunities  for  themselves  at  the  cost  of  the  VE. 

4.2.8.3  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column  C.c.c: 
Legal/Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown 
Structure 

Cell  concerns  how  assigning  or  reassigning  who  does  what  can  open  new  mar¬ 
kets. 

Examples: 

^Processes  which  recognize  that  by  moving  work  from  one  partner  to  another 
serves  a  specific  customer’s  future  Just  In  Time  workflow  requirements  to  the 
detriment  of  the  current  VE  workflow. 

^Redundancy  in  assigning  work  requirements  so  that  a  backup  exists  in  case  of 
problems. 

^Choosing  a  partner  for  a  specific  work  package  not  because  they  are  the  best  in 
that  area,  but  because  they  offer  a  greater  spectrum  of  VE-complementary  possi¬ 
bilities. 

4.2.8.4  Row  1 .3:  Opportunity  Identification:  Targeted  Market  and  Column  D.a.a: 
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Physical  Infrastructure:  Warehousing/Logistics:  Human  Collaboration 

Cell  concerns  the  strategies  for  getting  people  in  the  VE  together  physically  (or 
a  virtual  substitute)  in  order  to  identify,  analyze  and  pursue  new  VE  (and  individual) 
market  opportunities. 

Examples: 

4A  central  location,  suitably  designed  and  furnished,  which  hosts  regular  meet¬ 
ings  of  existing  and  potential  partners  for  the  purpose  of  market  targeting. 

4An  email  discussion  group,  or  a  paper  memo  distribution,  that  shares  substan¬ 
tial  information  on  leads  with  existing  and  potential  partners. 

dedicated  roving  person,  perhaps  an  independent  broker,  who  circulates 
among  partners  getting  and  sharing  market  ideas. 

4. 2. 8.5  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  C.a.e:  Legal/Explicit 
Infrastructure:  Business  Processes:  Depth  of  Customer  Relations 

Cell  concerns  how  relationships  with  existing  and  future  customers  are  mined 
to  identify  best  partners. 

Examples: 

4A  business  practice  which  involves  the  customer  in  searching  for  and  meaning¬ 
fully  evaluating  partners  to  meet  specific  needs  of  those  customers  which  may 
not  have  been  explicitly  identified  in  the  original  opportunity  scope. 

^Creation  of  an  experience  database,  shared  with  competitors,  of  positive  and 
negative  experiences  that  a  wide  variety  of  customers  have  had  in  similar  circum¬ 
stances. 

^A  VE-subsidized  activity-based  costing  analysis  of  a  customer’s  enterprise  to 
assure  that  the  VE  best  benefits  the  customer’s  value  chain  in  ways  that  may  not 
be  apparent  from  the  VE’s  perspective  alone. 

4.2.8.6  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  C.b.b:  Legal/ 
Explicit  Infrastructure:  Legal/Regulatory;  Risk/Reward  Contracts 

Cell  concerns  rewards  that  may  go  to  partners  for  identifying  new  partners,  even 
when  that  works  against  the  original  partners'  conventional  interests. 

Examples: 

4  A  broker’s  fee  which  shares  the  cost  of  savings  between  the  VE  and  a  partner 
when  that  partner  decreases  its  role  in  the  VE  to  the  benefit  of  the  VE  or  the  cus¬ 
tomer. 

^  ^A  VE-subsidIzed  risk  fund  that  pays  for  studies  within  partners  to  explore  ways 
of  working  with  their  competitors  in  precompetitive  areas. 

^  Labor  agreements  which  reward  evaluations,  and  perhaps  certification  of  part- 
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ners  with  whom  they  have  experience. 


4.2.8.7  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  C.c.c:  Legal/Explicit 
Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown  Structure 

Cell  concerns  how  it  is  decided  who  does  what  within  the  VE. 

Examples: 

^Agreements  with  the  customer  that  give  them  insight  into  the  process  of  and 
final  say  over  how  and  to  whom  the  work  is  assigned  within  the  VE. 

4 Dynamic  agent  systems  that  quickly  and  cheaply  support  bidding  among  many 
warm  partners  who  are  competitors  who  can  do  the  same  work. 

4A  process  for  creating  spin-offs  from  the  VE  or  partners  that  have  key  capabili¬ 
ties  that  are  only  available  to  the  VE  and  successors  (defined  somehow). 

4.2.8.8  Row  2.3:  Partner  Selection:  Partner  Search  and  Column  D.a.a:  Physical 
Infrastructure:  Warehousing/Logistics:  Human  Collaboration 

Cell  concerns  support  for  physical  space  wherein  representatives  from  potential 
partners  can  come  to  be  evaluated. 

Examples: 

^An  assessment  center  for  potential  partners  to  evaluate  how  well  they  fit  in  oth¬ 
ers  projected  on  the  team,  and  how  they  respond  to  change  within  the  engi¬ 
neered  VE.  This  presumes  that  performance  on  the  actual  task  is  known. 
^Maintenance  of  a  centralized  database  of  prequalified  partner  information. 

4A  regular  retreat  location  where  customers,  brokers/consultants,  and  prospec¬ 
tive  partners  explore  not  what  they  do,  but  be  aware  of  what  they  might  do. 

4.2.8.9  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column  C.a.e:  Legal/ 
Explicit  Infrastructure:  Business  Processes:  Depth  of  Customer  Relations 

Cell  concerns  how  the  relationship  with  the  customer  is  exploited  to  incentivize 
behavior  deep  within  the  VE  that  benefits  the  customer,  the  VE  and  the  partners. 

Examples: 

^Training  sessions  which  increase  the  awareness  throughout  the  supplier  chain 
of  how  the  VE  supports  the  customer,  and  how  each  function  results  in  profit. 

4 A  partner  within  the  VE  whose  primary  mission  is  to  act  as  advocate  for  the  cus¬ 
tomer  (or  the  customer’s  customer),  and  which  provides  input  to  the  initial  part¬ 
nering  negotiations. 

^A  simulation  tool  that  exercises  several  models  of  reward  strategies  and  break¬ 
downs  with  the  intent  of  optimizing  continuing  linkage  to  the  customer. 
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4.2.8.10  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column  C.b.b:  Legal/ 
Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Contracts 

Cell  concerns  the  actual  contract  support  for  the  risk/reward  strategy. 
Examples: 

^Contract  negotiations  for  forming  the  VE  are  conducted  by  an  outside  legal 
contractor  whose  remuneration  is  tied  to  the  success  of  the  VE. 

4A  major  portion  of  each  partner’s  payments  are  tied  to  shares,  percentages  of 
the  VE’s  profits. 

major  portion  of  the  capitalization  of  the  VE  comes  from  the  partners  in 
rough  distribution  to  the  profit  to  each  expected. 

4.2.8. 1 1  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column  C.c.c:  Legal/ 
Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown  Structure 

Cell  concerns  the  linkage  between  determining  who  does  what,  and  who  gets 
paid  how  much. 

Examples: 

4 A  pricing  system  that  is  not  tied  to  extra*VE  market  pricing,  but  instead  special 
intra-VE  value-added  analysis. 

system  that  accords  influence  over  the  management  of  the  VE  (controlling 
votes),  based  on  the  value  added  by  each  constituent, 

4 A  flexible  system  for  rewarding  partners  for  suggesting  ways  to  improve  the 
work  breakdown  (and  other  VE  roles). 


4.2.8.12  Row  3.6:  VE  Formation:  Risk/Reward  Strategies  and  Column  D.a.a: 
Physical  Infrastructure:  Warehousing/Logistics:  Human  Collaboration 

Cell  concerns  how  human  interaction  among  VE  partners  is  managed  to  assure 
that  trust  is  maintained. 


Examples: 

4A  regular  retreat  where  partners’  representatives  can  not  only  relax  and  social¬ 
ize  but  also  air  problems  and  misunderstandings. 

^A  dedicated  consultant  which  travels  from  partner  to  partner  to  brief  what  the 
other  players  do  and  to  carry  concerns  from  one  to  the  other,  presumably  also 
conducting  team-building  exercises. 

^A  partner  dedicated  to  arbitration,  using  a  central  database  of  performance 
metrics  on  each  of  the  partners. 


4.2.8.13  Row  4.1:  VE  Operation:  Performance  Metrics  and  Column  C.a.e:  Legal/ 
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Explicit  Infrastructure:  B  jsines!  Processes:  Depth  of  Cusromer  Relations 

Cell  concerns  the  metnod  of  using  custou  c  r  sat  jfactiDn  to  evaluate  how  well 
each  activity  in  the  VE  is  performing. 

Examples: 

^An  activity  evaluation  wh  ch  determines  lot  only  whether  each  member  is 
doing  what  was  expected,  but  also  the  ex  tent  to  which  it  adds  to  customer  satis¬ 
faction. 

4 Benchmarking  to  compare  whatif  changes  in  the  VE  to  competitors’  offerings. 

^Quality  of  life  audits  to  determine  whether  market  forces  are  optimizing  the 
well-being  of  the  customer  and  the  VE. 

4.2.8.14  Row  4.1:  VE  Operation:  Performance  Metrics  and  Column  C.b.b:  Legal/ 
Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward  Contracts 

Cell  concerns  the  level  of  connection  between  partner  reward  and  real-time 
monitoring  of  performance. 

Examples: 

^Quality  metrics  tied  to  partner  payments. 

^Customer-generated  agility  metrics  tied  to  partner  payments. 

^Metrics  which  weight  reimbursement  for  investment  based  on  the  level  of  risk 
involved. 

4.2.8.15  Row  4.1:  VE  Operation:  Performance  Metrics  and  Column  C.c.c:  Legal/ 
Explicit  Infrastructure:  WorkFlow  (Business  Plan):  Work  Breakdown  Structure 

Cell  concerns  how  the  work  is  divided  in  order  to  be  monitorable  by  the  VE. 

Examples: 

4 A  lingua  franca  within  the  VE  which  allows  each  participant  to  understand  the 
performance  if  its  partners. 

4A  set  of  product  and  corporate  responsibility  boundaries  that  corresponds  to 
measurable  process  boundaries. 

generic,  comprehensive  set  of  performance  measures  that  can  be  used  to 
advertise  and  contract  for  services  from  a  pool  of  new  partners. 

4.2.8.16  Row  4.1:  VE  Operation:  Performance  Metrics  and  Column  D.a.a:  Physical 
Infrastructure:  Warehousing/Logistics:  Human  Collaboration 

) 

Cell  concerns  how  human  collaboration  within  the  VE  is  measured. 

Examples: 
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^Qualitative  measures  for  the  level  of  quality  in  collaboration  among  team  mem¬ 
bers. 

4A  specific  assessment  center  for  evaluating  (and  improving)  intercompany  col¬ 
laborative  team  functioning. 

^Support  for  extracorporate,  extra-VE  teams,  such  as  labor  unions. 

4.2.8.17  Row  5.1:  VE  Reconfiguration/Dissolution:  Identify  Need  for  Change  and 
Column  C.a.e:  Legal/Explicit  Infrastructure:  Business  Processes:  Depth  of 
Customer  Relations 

Cell  concerns  the  way  the  VE  gets  indications  from  the  customer  that  the  VE 
needs  to  change  (or  blink  out). 

Examples: 

^Dedicated  agents  (persons)  in  key  partners  whose  primary  job  is  sensing  the 
customer  for  changes  in  the  opportunity  which  mobilized  the  VE. 

^Agents  who  deliberately  destabilize  the  market  in  controlled  ways  to  sense  and 
create  new  trends. 

^Processes  which  examine  unrelated  markets  for  analogies  which  may  indicate 
general  technical,  economic  and  social  trends. 

4.2.8.18  Row  5.1:  VE  Reconfiguration/Dissolution:  Identify  Need  for  Change  and 
Column  C.b.b:  Legal/Explicit  Infrastructure:  Legal/Regulatory:  Risk/Reward 
Contracts 

Cell  concerns  how  partners  get  reimbursed  for  sensing,  communicating  and  act¬ 
ing  on  the  need  for  change. 

Examples: 

4 A  reward  pool  for  agents,  perhaps  deep  in  the  supply  base,  who  report  sus¬ 
pected  changes  that  are  later  validated. 

4An  investment  pool  which  subsidizes  internal  R&D  in  a  partner  which  could 
effect  the  that  partner’s  role,  someone  else  in  the  VE,  or  the  customer. 

^Disincentives  for  partners  which  focus  on  a  narrow,  inflexible  customer  need 
which  is  susceptible  to  change. 

4.2.8.19  Row  5.1:  VE  Reconfiguration/Dissolution:  Identify  Need  for  Change  and 
Column  C.c.c:  Legal/Explicit  Infrastructure:  WorkFIow  (Business  Plan):  Work 
^Breakdown  Structure 

Cell  concerns  how  the  VE  is  decomposed  in  a  way  that  eases  the  identification 
of  change  and  the  change  itself. 
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Examples: 

work  breakdown  structure  which  is  designed  in  such  a  way  to  make  processes 
relatively  independent;  processes  and  players  can  be  swapped  without  major 
change  among  other  partners. 

^Work  breakdown  of  VE  control  functions  which  makes  it  difficult  for  each  part¬ 
ner  to  not  be  alert  to  change,  for  instance  by  having  each  process  responsible  for 
its  own  comparative  value-added  audit. 

^Elimination  of  a  dominant  prime,  so  that  the  roles  of  leadership  is  forced  into 
innovative  reinventing  in  order  to  preserve  the  frangible  institution. 

4.2.8.20  Row  5.1:  VE  Reconfiguration/Dissolution:  Identify  Need  for  Change  and 
Column  D.a.a:  Physical  Infrastructure:  Warehousing/Logistics:  Human 
Collaboration 

Cell  concerns  how  partners  interact  to  identify  the  need  for  change  and  planning 
for  change. 

Examples: 

4A  simulation  center  where  partners  use  role  playing  to  identify  future  problems 
in  the  market,  and  in  external  change  forces. 

4 A  process  where  employees  are  shifted  from  one  partner  to  another  for  long 
periods  with  the  primary  goal  of  cross-fertilizing  ideas  for  improvement. 
^Workforce  collaborative  and  educational  practices  which  produce  High  Perfor¬ 
mance  Workforces  (that  is,  those  which  support  a  culture  likely  to  drive  innova¬ 
tion). 

4.3  Best  Agile  Practice  Examples 

(The  Reference  Model  was  generated  in  the  context  of  a  significant  number  of  case  studies.  Eight  examples  are 
given  here.) 

The  Focus  Group  created  the  Reference  Model  and  associated  definitions  in  con¬ 
cert  with  a  major  effort  in  surveying  best  practices  in  agility.  Although  we  had  ex¬ 
tensive  involvement  in  the  group,  it  was  essential  for  us  to  have  something  real  to 
discuss. 

In  addition  to  the  important  work  of  helping  with  the  mode  discovered  a  few 
things: 

^Needless  to  say,  there  are  no  cases  where  an  enterprise  has  deliberately  engi¬ 
neered  agility  into  the  system.  The  tools,  such  as  metrics,  did  not  exist,  so  such 
engineering  was  Impossible.  So  we  captured  agility,  even  when  it  was  accidental. 

,  4There  are  no  cases  that  we  found  where  the  VE  was  wholly  agile.  We  captured 
cases  where  agility  was  manifest  in  some  notable  area. 

4There  are  no  fully  Type  1  or  2  VEs.  We  surveyed  relatively  conventional  VEs. 
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^AII  were  agile  in  either  VE  formation  or  operation,  but  not  both. 

About  fifty  sites  were  identified  based  on  insights  from  the  group  and  the  larger 
virtual  group.  These  were  interviewed  by  phone  and/or  email,  and  nearly  twenty 
were  visited.  Eight  were  deemed  useful  cases  for  discussion  outside  the  group. 
Half  of  these,  four,  insisted  on  anonymity.  More  than  half  of  those  surveyed  overall 
had  concerns  which  would  have  resulted  in  similar  restrictions. 

Specific  case  reports  follow: 


Name 

Type 

Sector 

Anon  Railroad 

2 

Svc 

FlexCell 

4 

Mfg 

Sikorsky 

1P 

Mfg 

Anon  Elex  Mfr 

1 

Mfg 

Westinghouse 

Mfg 

Anon  Airline 

4 

Svc 

Anon  Shipyard 

3 

Mfg 

Taligent 

1p 

“Mfg” 

4.3.1  Anonymous  Railroad 

|A  railroad  forms  virtual  enterprises  on  behalf  of  future  freight  users.  How  they  identify  opportunities  is  novel.) 

This  anonymous  case  concerns  a  major  railway.  Surveyed  was  its  ability  to  part¬ 
ner  with  a  potential  industrial  firm  to  locate  at  a  site  which  would  be  served  in  per¬ 
petuity  by  the  railroad.  It  is  a  qualified  Type  2  AVE. 

The  strength  of  railroads,  like  local  phone  and  utility  suppliers,  is  built  on 
growth.  Some  growth  comes  from  increased  use  from  the  existing  base,  but  the 
most  important  growth  comes  from  new  users.  With  railroads  this  means  attract¬ 
ing  certain  industries  to  sites  which  are  or  can  be  served  by  their  rail.  In  other 
words,  stockholder  value  can  only  be  increased  if  other  firms,  the  rails'  customers, 
grow. 

This  rail  company  has  been  remarkably  successful  in  matching  sites  and  firms, 
thus  strongly  outpacing  its  competitors  in  growing  its  sustaining  base. 

The  best  practices  is  this  case  are  in  the  opportunity  identification  and  partner 
selection.  A  full-time  staff  is  dedicated  to  these  tasks.  They  are  independent  of  the 
traditional  sales/marketing  staff,  and  enjoy  a  high  status  and  priority  over  resourc¬ 
es  in  the  firm. 

^  There  appear  to  be  several  facets  of  how  these  best  practices  are  executed: 
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A  set  of  long-lived  partnerships  have  been  established  to  support  the  needs  of 
the  short-term  VE  partnership.  These  partners  are  of  two  types:  those  who  share 
the  goals  of  the  VE  (local  utilities,  municipal/state  economic  development  author¬ 
ities,  local  chambers  of  commerce,  possibly  unions),  and  those  that  provide  sup¬ 
porting  analytical  and  consulting  services. 

This  team  is  entirely  opportunity  driven. 

The  rail  company  employs  a  staff  (which  uses  consultants)  to  keep  current  a  col¬ 
lection  of  knowledge  about  trends  in  certain  industries  which  traditionally  use  rail 
service.  State  of  the  art  market  prediction  tools  are  employed.  In  some  cases,  this 
mirrors  (but  is  independent  of)  similar  forecasts  going  on  the  firms  in  those  sec¬ 
tors.  The  purpose  of  these  analyses  is  to  anticipate  an  industrial  need  which  is  like¬ 
ly  to  be  served  by  assets  in  the  rail's  geographic  area. 

The  rail  company  does  not  wait  for  a  firm  to  take  action  on  a  need,  but  actively 
seeks  them  out  with  their  results.  Often  when  the  businesses  are  approached,  they 
have  independently  determined  the  need  (opportunity).  But  sometimes  they  have 
not  and  are  surprised,  in  which  case  they  often  welcome  the  information. 

Because  the  rail  line  has  good  operations  research  skills  from  its  running  of  the 
railroad,  it  has  developed  good  operations  research-based  tools  to  keep  the  focus 
of  expensive  analyses  narrow  and  the  approaches  limited  to  high  payoffs.  This  is 
the  key  to  entire  endeavor  and  could  form  the  basis  of  Opportunity  Strategy  met¬ 
rics. 

Agility  comes  into  play  here.  The  nature  of  the  tools  is  two-fold:  one  edition  of 
tools  looks  at  long-lived  trends.  The  other  edition  is  optimized  to  analyze  surpris¬ 
es,  to  look  for  new  niches  opened  by  the  surprise.  This  latter  set  is  adapted  from 
tools  developed  by  a  commodities  speculation  firm. 

One  feature  of  the  tools  is  remarkable.  Each  analysis  needs  to  have  two  faces: 
one  which  shows  risk/reward  of  the  core  business  of  the  (at  this  point  unknown) 
manufacturer;  and  another  which  shows  the  risks/rewards  to  the  rail  company. 

The  rail  company  does  not  expose  itself  to  a  partner  until  it  has  been  identified 
by  its  in-house  work.  (Of  course,  there  are  cases  where  a  partner  is  out  looking  for 
a  site  and  calls  on  the  rail  company  or  municipality,  but  that's  another  situation.) 
Hardly  anyone,  much  less  the  rail  company's  competition  knows  the  extent  of  the 
behind  the  scenes  analysis. 

The  rail  company  learned  early  on  to  limit  its  target  markets  to  only  those  in¬ 
dustrial  situations  where  their  geographic  strengths  (supplemented  by  the  efforts 
of  the  cities,  etc.)  are  clearly  strong.  A  best  practice  appears  to  be  that  the  target 
market  determination  is  largely  made  by  each  partner  before  introducing  them¬ 
selves.  The  partner-specific  spins  on  this  determination  form  the  basis  for  all  VE 
decisions  which  follow. 

One  winning  feature  of  the  evaluation  is  the  weighting  in  favor  of  foreign  firms 
^ho  do  not  yet  have  US  plants,  and  therefore  regional  entanglements.  Maintaining 
the  capability  of  addressing  this  involves  having  staff  or  available  consultants  who 
can  speak  several  languages  (and  understand  the  partner's  local  business  signals). 
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The  same  operations  research-based  metrics  from  above  come  to  bear  on  the 
need  for  marrying  non-U.  S.  business  practice  to  those  of  the  U.  S. 

There  is  no  partner  search  as  such.  It  appears  to  be  a  best  practice  that  the 
search  criteria  are  built  into  the  opportunity  strategy  and  are  not  an  afterthought. 
In  other  words,  the  opportunity  analysis  determines  not  only  (for  example)  that  a 
new  fertilizer  plant  can  be  justified,  but  also  which  firm  is  the  strongest  to  succeed 
at  it. 

What  results  is  the  formation  of  temporary  VE  with  the  intent  of  getting  the  tar¬ 
get  firm  established  and  operating.  Many  interesting  stories  were  reported,  involv¬ 
ing  core  competencies  specific  to  the  occasion.  None  generic  were  perceived 
except  the  strength  of  the  local  VE  to  handle  the  unexpected  issues  thrown  at  the 
newcomer.  Once  that  newcomer  is  established,  it  begins  its  normal  business,  and 
the  VE  is  dissolved. 

Legal  agreements  are  light,  and  often  largely  overlooked. 

4.3.2  FlexCell 

[A  successful  bidding  coalition. | 

FlexCell  Is  a  collection  of  small  businesses,  banded  together  for  collective  busi¬ 
ness  development.  Their  business  is  focused  on  small  lots  of  machined/manufac¬ 
tured  parts  and  associated  services. 

They  are  a  Type  4  AVE,  using  conventional  practices  for  most  of  the  reference 
base  subcategories  with  the  following  exception. 

The  partners  are  nearly  exclusively  drawn  from  a  closed  group,  geographically 
limited.  Membership  in  the  collaborative  Is  built  around  decision  makers  in  the 
firms.  Prequalification  is  achieved  by  history  and  trust,  incubated  by  encounter- 
group  like  techniques  and  socialization.  The  key  best  practice  is  the  assignment  of 
a  full-time  person  whose  goal  is  build  and  maintain  that  trust  over  several  years. 

The  link  is  exclusively  within  the  Social/Cultural  infrastructure. 

This  practice  leverages  local,  agriculturally-based  values  of  honesty  and  constan¬ 
cy.  It  also  appears  to  depend  on  a  rare,  high  energy  Individual. 

There  does  not  appear  to  be  an  Indication  for  a  metric.  The  metric  is  binary:  if 
you  compromise  the  trust  factor  Incubated  by  the  group,  you  are  likely  to  be 
shunned. 

This  group  is  trying  to  develop  some  legal  infrastructure  though  a  shared  financ¬ 
ing  mechanism,  but  there  is  no  track  record  or  Legal  best  practice  yet. 

4.3.3  Sikorsky 

[Capturing  key  processes  for  transfer  to  partners  of  convenience.] 

I  Sikorsky  Aircraft,  a  $2.3B  corporation,  manufactures  both  commercial  and  mili¬ 
tary  helicopters.  The  VE  effort  surveyed  here  examines  how  a  permanent  Type  1 
VE,  still  in  creation,  is  leveraging  a  specific,  valuable  best  practice. 
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Sikorsky,  as  with  essentially  all  helicopter  manufacturers,  has  in  the  past  relied 
on  a  stable  base  of  military  orders.  Recently,  that  military  base  has  sharply  declined 
and  its  future  is  in  question.  The  firm  has  responded  by  designing  a  helicopter  with 
potentially  broad  appeal  to  commercial  and  international  users.  Sikorsl^r  realizes 
that  they  must  respond  to  a  price  driven  market  yet  still  deliver  quality  products 
with  high  performance  on  time. 

This  craft,  the  S-92,  is  not  wholly  new,  being  derived  from  their  successful  Black- 
Hawk  series.  The  new  design  primarily  adds  internal  cabin  space  and  modified  sub¬ 
systems  so  that  the  derivatives  can  be  brought  to  market  relatively  quickly  and 
inexpensively. 

However,  a  new  product  requires  customers,  and  in  the  S-92's  case,  key  custom¬ 
ers  are  international.  These  international  concerns  will  require  that  at  least  their 
machines  are  manufactured  in  their  countries  in  some  sort  of  joint  venture.  There¬ 
fore,  Sikorsky  is  necessarily  in  the  Virtual  Enterprise  business.  Sikorsky  is  familiar 
with  teaming  and  has  recent  experience  integrating  product  and  process  with  Boe¬ 
ing  on  the  Commanche.  But  partnering  with  the  S-92  partners  will  be  very  much 
more  difficult  because  of  cultural  and  technical  barriers  as  well  as  the  need  for 
speed. 

What  is  novel  about  this  case  is  a  specific  infrastructure  investment  that  is  being 
made.  This  investment  will  greatly  improve  the  ability  to  agily  form  Virtual  Enter¬ 
prises  and  is  a  best  practice  of  an  early  phase  of  the  VE. 

The  problem  is  one  of  transferring  key  elements  of  some  manufacturing  practic¬ 
es  to  a  partner  and  integrating  those  with  other  practices  of  Sikorsl^^,  who  will  act 
as  prime  contractor.  In  that  role,  the  prime  is  responsible  for  quality  throughout 
the  aircraft.  Cases  in  similar  (non  Sikorsky)  situations,  has  demonstrated  that  the 
detailed  definition  of  and  integration  to  processes  is  a  difficult  job  which  has  not 
yet  been  done  well 

Sikorsky  has  an  ambitious  effort  underway  to  introduce  small  knowledge  bases 
to  key  processes  associated  with  manufacturing  engineering.  Rule  Based  Technol¬ 
ogy  (RBT)  is  used  to  create  a  tool  to  perform  some  special,  bounded  function  asso¬ 
ciated  with  an  engineering  process.  This  tool  is  usually  embedded  in  the  3-D  CAD 
environment.  Therefore  it  has  a  dual  nature:  it  is  both  a  part  of  the  process,  and 
contains  explicit,  expert  knowledge  about  the  process. 

About  two  dozen  of  these  knowledge  projects  are  underway.  Some  relate  to  su¬ 
pervisory  or  oversight  functions,  and  most  concern  the  relationship  among  design, 
manufacturing  engineering,  and  the  manufacturing  process.  Typically,  a  Imowl- 
edge  project  is  scoped  at  6  months  and  2000  hours  for  the  first  benefits.  The  effort 
is  well  past  the  stage  where  management  is  identifying  isolated  problem  process¬ 
es.  Now,  individual  engineering  managers  are  growing  the  projects  into  adjacent 
processes  so  that  knowledge  about  communicating  processes  is  captured. 

^  The  most  difficult  areas  are  being  addressed  first.  The  effect  of  this  preparation 
is  that  key  processes  are  being  super-modeled  in  knowledge  based  tools  that  can 
be  leveraged  for  the  AVE.  Two  effects  are  apparent. 

^First,  the  tools  literally  replace  expertise,  usually  held  by  a  group  of  cross-func- 
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tional  experts.  Since  the  expertise  is  packaged,  that  expertise  can  be  quickly 
transferred  to  a  partner  in  the  form  of  tools.  Obviously,  the  resulting  fabric  of 
processes  which  incorporate  these  tools  will  strongly  resemble  Sikorsky's,  mak¬ 
ing  team  integration  and  reconfiguration  much  easier. 

second  effect  is  an  extension  of  one  well-known  benefit  of  modeling.  By  mak¬ 
ing  the  expertise  explicit  in  the  knowledgebase,  Sikorsky  gains  insight  into  the 
process  itself.  This  allows  for  benefits  in  a  number  of  dimensions.  One  cogent  to 
Agile  Virtual  Enterprises  is  that  the  boundaries  between  processes,  and  their 
metrics,  become  more  formal  and  trackable.  These  boundaries  will  be  essential 
for  fine-grained  assignment  of  the  work  balance  among  partners. 

Note  that  the  coarse  division  of  the  aircraft  among  partners  will  be  based  on 
largely  political  factors,  not  on  an  informed  analysis  of  the  manufacturing  process¬ 
es.  It  makes  the  integration  of  fine-grained  processes  much  more  difficult.  This  is 
especially  so  considering  that  the  responsibility  (and  liability!)  for  the  craft  resides 
with  the  prime. 

Certainly  this  early  investment  will  reap  major  payoff  as  the  VEs  are  formed.  It 
is  interesting  therefore  that  none  of  the  investment  was  justified  in  terms  of  the 
AVE  benefits.  Instead,  a  rigorous  return  on  investment  case  is  made  for  each  knowl¬ 
edge  project  with  benefits  on  existing,  in-house  work  within  a  year.  Those  cases 
which  have  been  completed  have  resulted  in  substantial  savings  when  considered 
locally,  that  is,  without  consideration  to  the  S-92  and  the  VE. 

The  Best  Practice  here  is  assigned  to  Partner  Qualification,  but  could  be  spread 
over  at  least  a  couple  reference  base  subcategories. 

^Operating  Structure  (in  part)  covers  the  processes  of  harmonizing  cultures, 
integrating  processes,  and  establishing  what  in  this  case  is  the  supervisory  role 
of  the  prime  over  quality.  The  Best  Practice  is  in  making  those  three  elements 
explicit  and  portable  before  entering  into  the  confusing  period  of  actually  estab¬ 
lishing  the  VE. 

^Partner  Qualification.  This  case  adds  something  to  the  Focus  Group's  under¬ 
standing  of  this  subcategory.  In  this  case,  the  partners  are  selected  for  reasons 
which  are  not  primarily  based  on  capability.  Thus,  Sikorsky  assumes  some 
responsibility  to  make  the  partners  qualified.  The  greater  Sikorsky's  ability  to 
Insert  technology  into  partners,  the  greater  the  pool  of  potential  partners  and 
therefore  the  larger  the  number  of  countries  which  can  be  addressed. 

We  would  expect,  with  further  study,  to  find  some  leverage  for  metrics  here. 
The  place  to  look  is  the  boundary  of  the  knowledge  project.  We  noted  that  these 
projects  are  often  rescoped  to  make  them  larger  or  smaller,  so  that  they  represent 
a  meaningful  process  module  of  a  handy  size. 

The  case  hasn't  yet  addressed  the  four  infrastructures.  We  expect  that  the  major 
Impact  will  be  on  the  cultural  infrastructure:  the  use  of  these  tools  by  the  partner{s) 
yill  necessarily  bring  most  of  the  manufacturing  engineering  (but  not  manufactur¬ 
ing)  processes  into  harmony  with  Sikorsky. 
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The  Information  Infrastructure  play  is  indirect:  rule-based  representation  tools 
are  in  a  support  role,  not  as  a  driver.  But  Sikorsky  is  finding  that  legacy  systems 
may  be  problematic.  For  instance,  the  S-92  is  based  on  the  BlackHawk,  much  of 
which  was  not  exclusively  designed  using  CAD  methods.  Therefore,  a  conversion 
of  legacy  data  to  3D  CAD  models  may  be  required  to  fiilly  take  advantage  of  the 
best  practice. 

Probably,  this  practice  would  only  work  in  a  matrixed  organization,  where  func¬ 
tional  responsibilities  across  the  company  are  well  defined.  The  result,  in  a  firm 
like  Sikorsky,  is  that  each  Rule  Based  Technolo^  knowledge  project  is  dual-use, 
equally  applicable  to  military  and  commercial  aircraft. 

Sikorsky  managers  expect  many  of  these  projects  to  be  portable  to  other  indus¬ 
tries  as  well.  Chrysler,  for  example,  has  a  similar  Rule  Based  Technology  initiative. 
Their  CAD  checker  project  is  being  used  in  8  other  firms,  most  not  in  the  auto  busi¬ 
ness. 

4.3.4  Anonymous  Electronics  Manufacturer 

jPartners  are  evaluated  in  part  on  the  potential  for  differing  types  of  liabilities.) 

This  case  concerns  an  anonymous  large  consumer  electronics  manufacturing 
firm.  (Only  certain  features  of  the  VE  can  be  discussed.) 

The  example  involves  this  firm  entering  into  a  Type  1  VE  in  the  key  best  practice, 
and  a  Type  2  otherwise. 

The  background  is  that  many  consumer  electronics  markets  require  very  fast 
ramp-ups  of  manufacturing  capability  to  take  advantage  of  a  need,  a  niche,  or  to 
round  out  a  product  line. 

A  fairly  large,  promiscuous  base  of  suppliers  exist  to  help  address  this  need. 
Some  only  manufacture  for  others,  and  some  are  firms  who  manufacture  their  own 
brand  names  in  the  same  markets.  In  many  cases,  our  firm,  and  many  like  it,  would 
job  out  the  entire  product,  adding  only  the  brand  name  (and  some  design). 

In  the  past,  the  firm  would  use  fairly  simple  criteria  to  select  partners:  cost,  and 
schedule.  Quality  was  an  issue,  but  only  insofar  as  requiring  the  partner  to  meet 
certain  minimum  standards.  Notably,  strategic  issues  have  not  been  a  factor;  such 
issues  might  include  selecting  a  supplier  to  keep  it  away  from  a  competitor,  or  not 
selecting  it  because  of  fear  of  creating  a  future  competitor. 

What's  new  in  how  partners  are  selected  now  is  that  liability  is  becoming  an  is¬ 
sue. 

Two  kinds  of  liability  are  now  considered.  The  product  carries  a  liability.  Gener¬ 
ally,  the  liability  is  of  two  types  (which  overlap).  The  simple  type  deals  with  product 
failure:  the  downstream  cost  of  products  which  fail  for  reasons  not  covered  by  ne¬ 
gotiated  specifications  after  the  VE  is  dissolved.  The  more  dangerous  product  lia- 
^bility  is  the  potential  that  the  product  will  cause  damage,  resulting  in  costly  suits 
or  recalls. 


F ctruary  IS,  1997 


94- 


Part  1,  Metrics  Handbook 


Another  type  of  liability  is  also  important:  liability  associated  with  the  process. 
Generally  this  consists  of  the  risk  of  latent  environmental  damage,  workplace  suits 
(harassment/discrimination),  and  intellectual  property  infringements. 

This  firm  now  performs  analyses  on  potential  partners  to  evaluate  all  these  lia¬ 
bilities.  They  are  combined  with  other,  traditional  measures  in  selecting  partners. 

This  best  practice,  therefore,  is  in  the  subcategory  of  Partner  Qualification, 
though  it  impacts  Product  Liabilities  and  Risk/Reward  Strategies  processes  later  in 
the  formation  process.  What's  so  interesting  is  that  the  practice  directly  employs 
(actually  creates)  metrics. 

These  metrics  are  quantitative  and  can  be  easily  converted  to  dollars.  The  tech¬ 
niques  used  were  derived  from  actuarial  techniques  developed  by  insurance  actu¬ 
aries.  This  involves  a  special  methodology  for  modeling  the  processes  of  interest. 
The  processes  are  captured  in  this  specific  way,  which  often  involves  field  surveys. 
Then,  special  analytical  tools  are  used. 

A  large,  historical  database  (including  information  from  other  actuarial  domains) 
is  also  used. 

It's  notable  that,  while  the  firm  sponsored  the  development  of  the  metric  and 
process,  it  was  developed  and  is  wholly  performed  by  a  captive,  but  independent 
consulting  firm.  My  understanding  of  the  process  is  that  it  would  be  applicable  to 
a  wide  variety  of  AVE  applications.  But  it  may  be  difficult  to  blast  it  free,  since  it  is 
a  very  valuable  competitive  tool. 

Obviously,  the  impact  is  on  the  legal  infrastructure  more  than  the  other  cases. 
4.3.5  Westinghouse 

(Partners  drive  a  part  of  the  opportunity  identification  when  is  determined  by  emerging  processes.) 

The  case  involves  a  division  of  Westinghouse,  since  sold  to  Northrop  Grumman, 
that  supplies  complex  electronic  products.  The  dominant  customer  is  the  U.  S. 
government.  As  with  many  suppliers  of  complex  goods  with  a  large  supplier  base, 
Westinghouse  has  begun  to  reduce  and  prequalify  its  supplier  base.  Probably,  the 
firm  is  in  the  world-class  category  in  how  they  manage  this  process,  independent 
of  agility. 

The  best  practice  of  interest  to  the  VE  is  related  to  how  they  take  advantage  of 
their  supplier  base.  The  sector  in  which  Westinghouse  competes  is  characterized 
by  many  bidding  situations  coupled  with  a  remarkable  need  for  keeping  up  (or 
leading  with)  advanced  product  and  process  technologies.  In  conventional  suppli¬ 
er  relationships,  technology  and  bidding  strategies  trickle  down  to  the  suppliers, 
having  been  determined  at  the  top. 

Westinghouse,  however  has  well-developed  mechanisms  to  involve  their  suppli¬ 
ers  as  partners  in  both  strategic  technology  planning  and  competitive  bid  develop- 
^ment. 

As  the  supplier  base  has  narrowed,  supplier  liaison  personnel  have  increased 
their  scope  to  include  the  entire  product  development  cycle.  Suppliers  are  contin- 
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ually  surveyed  for  potentially  advantageous  new  skills  and  processes  which  might 
add  to  the  overall  competitiveness  of  the  Type  3  VE.  Once  an  opportunity  to  bid  has 
been  identified,  the  portfolio  of  new  processes  is  surveyed  for  advantage. 

Therefore,  when  the  bid  is  developed,  the  suppliers  become  involved  in  a  more 
peer-to-peer  way  than  their  competition. 

The  ability  of  a  supplier  to  work  with  Westinghouse  in  this  closer  manner  is  one 
of  the  criteria  used  in  searching,  evaluating  and  prequalifying  partners. 

4.3.6  Anonymous  Airline 

|A  novel  way  of  fencing  off  a  partner's  relationships  with  competitors  for  a  special  project.] 

This  case  is  an  anonymous  airline.  The  VE  effort  surveyed  how  a  Type  4  VE  is 
employed  to  provide  market  guidance  using  partners  which  are  also  partnered 
with  competitors. 

Domestic  airlines  have  lost  a  lot  of  money  in  the  past  few  years,  and  this  airline 
has  been  heavily  hit.  Most  airlines  are  substantially  constrained  In  the  changes  they 
can  make  in  costs  and  price.  Costs  can  be  squeezed  somewhat,  but  only  to  a  point. 
The  price  charged  is  a  matter  of  a  game  largely  unconnected  to  what  to  the  prod¬ 
uct  costs.  One  airline  has  to  meet  another's  price,  while  lowering  prices  on  other 
routes  offensively. 

In  this  environment,  airlines  are  desperate  to  differentiate  themselves,  to  create 
brand  loyalty.  The  frequent,  business  traveler  is  the  target.  To  this  end,  all  major 
airlines  have  frequent  traveler  programs.  All  of  these  programs  partner  with  essen¬ 
tially  the  same  set  of  hotel  and  rental  car  corporations,  in  a  near-Type  4  VE. 

However,  this  airline  was  able  to  use  its  partnership  to  develop  market  informa¬ 
tion  which  it  will  use  to  enhance  its  competitive  position,  while  preventing  similar 
information  to  flow  back  to  its  competitors.  The  result  is  a  marketing  strategy 
which  could  make  a  big  difference  in  saving  the  airline  by  creating  greater  business 
traveler  loyalty.  (The  specific  strategy  is  not  mentioned  here.) 

How  this  was  accomplished  constitutes  a  best  practice. 

Each  frequent  traveler  point  program,  in  air,  car  and  hotel  industries  is  fully 
computerized.  The  typical  business  traveler  is  assiduous  in  assuring  his  points  are 
tracked,  so  gathering  Information  on  who  went  to  what  kinds  of  places  and  how 
often  is  an  easy  task.  Each  partner  sells  that  Information,  usually  for  a  discount 
against  the  traveler's  benefits. 

This  airline  wanted  to  go  much  further,  to  do  some  targeted  marketing  research 
to  identify  an  expected  unmet  need  that  they  could  address  better  than  the  com¬ 
petition.  They  wanted  to  get  this  information  without  direct  airline-to-traveler  In¬ 
terviews  for  various  reasons.  At  the  same  time,  they  realized  that  car  and  hotel 
firms  routinely  identify  and  address  needs  similar  to  those  they  sought. 

I  The  question  was:  how  to  use  their  partners  (primarily  hotel)  to  reprocess  old 
information  and  collect  new  information  without  letting  that  information  fall  into 
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the  hands  of  their  competitors.  The  situation  is  similar  to  many  shared  intellectual 
property  problems  in  design/manufacturing  VEs. 

The  Risk/Reward  Strategies  subcategory  was  supposed  to  address  ownership  of 
newly  generated  intellectual  property.  But  it  fails  to  address  the  situation  when 
that  property  originates  in  the  second-tier  partners,  but  takes  on  added  value 

through  the  VE.  This  case  indicated  an  expansion  of  the  definition  of  that  subcat¬ 
egory. 

•J”  this  case,  the  airline  negotiated  some  very  sensitive  legal  instruments.  Indi¬ 
viduals  (by  name)  in  each  organization  were  compartmentalized:  each  could  only 
work  in  the  context  of  the  VE  and  its  successor,  not  to  work  with  a  competitor  for 
specified  number  of  years. 

The  hotel  partners  were  limited  to  two  who  compete  in  different  markets  to 
avoid  friction  and  confusion.  These  hotel  partners  were  granted  preference  in  co¬ 
operative  marketing  when  the  new  service  begins,  in  addition  to  some  financial 
recompense. 

Some  physical  separation  of  workers  and  records  was  required,  as  well  as  some 
co-location.  (Unknown  to  the  airline  this  mirrors  a  solution  to  similar  intellectual 
property  problems  in  the  defense  and  aerospace  industries.) 

The  legal  agreements  treated  the  employees  (for  the  sake  of  intellectual  prop¬ 
erty)  as  if  they  were  employed  by  a  joint  venture.  A  line  of  supervision,  populated 
by  the  partners  was  established  just  for  these  issues  (policy,  arbitration).  No  other 
joint  venture  management  structure  was  created;  all  else  was  managed  under  con¬ 
ventional  buyer-supplier  frameworks. 

While  the  legal  and  physical  infrastructures  were  affected,  the  information  and 
cultural  infrastructures  were  not. 

The  VE  was  truly  agile  in  the  sense  of  disassembling  after  the  need  was  met,  to 
be  replaced  by  a  more  conventional  relationship.  However,  the  effort  went  so  well 
that  the  arrangement  may  be  revived  in  the  future  for  more  market  intelligence 
needs. 

Relevance  to  metrics  exists  in  the  nature  of  the  legal  documents  we  were  told, 
but  we  were  not  able  to  examine  those  agreements.  It  was  explained  that  statisti¬ 
cal  methods  were  used  to  determine  what  percentage  (or  portion)  of  the  Intellec¬ 
tual  property  was  generated  new  within  the  VE  and  which  originated  In  a  partner. 
We  got  the  impression  that  these  methods  were  derived  from  activity-based  cost¬ 
ing  methods,  meaning  the  cost  and  not  the  value  of  the  information  formed  the 
basis  of  the  metric. 


4.3.7  Anonymous  Shipyard 

|A  process  plan  for  a  new  business  area  is  manufactured  as  if  it  were  a  product  of  the  old  process  plan.) 

^  This  case  Is  an  anonymous  shipyard,  which  until  recently  was  mainly  involved  in 
U.  S.  Navy  work.  The  VE  effort  surveyed  here  is  how  a  Type  3  VE  was  used  to  bring 
core  competencies  to  bring  to  bear  and  accomplish  a  switch  to  commercial  busi¬ 
ness. 
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The  firm  surveyed  once  was  largely  a  commercial  yard.  But  for  the  last  few  de¬ 
cades,  no  new-ship  commercial  construction  had  occurred,  following  a  sorry  na¬ 
tional  trend.  The  Reagan  buildup  kept  the  yard  busy  until  recently.  A  combination 
of  predicable,  and  largely  non-predicable  (political  reversals)  forced  this  firm  to 
seek  an  agile  introduction  into  commercial  work. 

What  is  novel  about  this  case  is  how  they  leveraged  a  pool  of  suppliers  for  gov¬ 
ernment  work  into  a  VE  to  address  commercial  work. 

Building  a  naval  ship  is  an  interesting  business.  The  shipyard  acts  as  a  prime  con¬ 
tractor  for  a  weapon  system,  and  a  large  supply  chain  is  involved.  This  supply  chain 
changes  from  ship  to  ship,  but  consists  of  a  limited,  fairly  well-connected  commu¬ 
nity.  Many  of  the  practices  involved  in  installing  and  integrating  a  component  on 
a  ship  are  co-developed  between  the  prime  and  the  supplier. 

In  this  case,  the  prime  had  lost  its  corporate  knowledge  concerning  commercial 
practices.  But  that  knowledge  largely  existed,  in  a  distributed  fashion,  in  the  sup¬ 
plier  base.  If  the  yard  failed,  the  supplier  base  would  suffer.  So  the  prime/supplier 
relationships  were  supplemented  by  a  VE  to  transfer  commercial  skills  to  the 
prime. 

In  normal  commercial  yards,  the  job  of  estimating  the  job  (building  an  ship)  is 
relatively  disconnected  from  planning  and  building  the  ship.  In  military  work,  the 
two  are  more  closely  connected.  The  process  plan  is  sketched  out  for  the  estimate, 
then  fleshed  out  for  the  actual  building.  This  provided  leverage  for  the  prime  to 
commit  to  a  supplier  base,  conditional  on  getting  the  work.  Then  those  suppliers 
came  in  and  helped  develop  the  process  plan  (supporting  the  estimate),  working 
side-by-side  with  the  yard's  planners. 

The  VE  was  opportunistic,  based  only  on  the  one  buy.  Risks  were  shared,  a  rad¬ 
ical  change  for  the  supplier  base,  but  their  later  marketing  expenses  were  reduced. 

In  the  first  case,  the  buy  was  successful,  and  commercial  ships  will  be  built  by 
the  yard,  the  first  VE  reverting  to  a  traditional  supplier/prime  relationship.  Plans 
are  underway  to  use  this  mechanism  to  identify  and  address  unusual  and  niche 
market  commercial  work.  The  idea  is  that  they  can  address  these  new  and  unusual 
situations  faster  and  cheaper  by  relying  on  their  suppliers  to  help  develop  the  at- 
risk  process  plans  for  confident  bids. 

There  is  a  lesson  here  for  military  primes  who  feel  hampered  by  an  onerous  up¬ 
front  planning  culture.  It  can  be  turned  into  a  mechanism  to  bring  new,  commer¬ 
cial  skills  from  the  supplier  base  into  the  organization  via  a  VE. 

The  Best  Practice  here  focuses  on  Operating  Structure.  Besides  the  novelty  of 
the  idea,  the  yard  developed  a  way  to  coordinate  the  cacophony  of  bottom-up 
planning.  (They  were  used  to  a  more  top-down  philosophy.) 

The  development  of  the  bidding-level  process  plan  was  seen  as  a  manufacturing 
task  in  itself.  A  process  plan  for  that  (a  metaprocess  plan?)  was  developed  with 
identification  of  who  would  come  in  when,  for  roughly  how  long,  to  help  develop 
what  piece  of  the  shipbuilding  plan.  This  idea  of  planning  for  the  creation  of  a 
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working  structure  for  a  VE  is  powerful  one,  which  we  were  not  able  to  expand  be¬ 
yond  the  scope  of  the  shipbuilding  sector.  But  it  seems  generally  applicable. 

We  would  expect,  with  further  study,  to  find  some  leverage  for  metrics  here. 

Conventional  supplier/chain  legal  infrastructure  was  used  with  the  exception  of 
early  selection  for  at  risk  assistance. 

Physical  infrastmcture  was  Important,  with  facilitated  temporary  collocation  be¬ 
ing  essential.  Socialization  was  moderately  encouraged.  Participants  think  that 
more  of  this  would  help  next  time,  since  the  one  time  pressure  could  not  be  sus¬ 
tained.  information  infrastructure  was  not  a  factor.  In  the  sense  of  requiring  new 
capability. 

4.3.8  Taligent 

(Risk  and  Reward  strategies  make  a  software  developer  change  a  few  times  in  midstream.) 

Taligent  is  a  joint  venture,  a  permanent  Type  1  VE,  whose  charter  is  to  provide 
a  radical  improvement  in  the  ability  to  develop  and  use  software  In  enterprises. 
The  company  is  developing  a  next  generation  object  oriented  (00)  application  sys¬ 
tem  that  Is  portable  across  all  major  desktop  hardware  and  operating  system  en¬ 
vironments.  It  was  originally  formed  by  IBM  and  Apple  nearly  three  years  ago. 

Several  major  changes  have  been  made  since  its  formation.  A  new  major  part¬ 
ner,  Hewlett-Packard  was  brought  into  the  VE.  The  development  reference  plat¬ 
form  was  changed  from  Apple  Macintosh  68K  to  IBM  AIX  RS6000,  a  technical 
enhancement  in  response  to  developer  requirements.  The  mission  of  the  company 
was  changed,  based  on  customer  feedback,  from  deploying  a  single  integrated  00 
environment  to  providing  both  a  portable  application  system  that  rides  on  many 
operating  systems  and  a  separate  00  operating  system. 

The  focus  of  this  case  is  how  Taligent  has  been  able  to  listen  to  and  respond  to 
their  customers,  the  three  investors,  as  partners  and  outside  customers,  while  jug¬ 
gling  the  realities  of  competitive  versus  precompetitive  issues. 

Three  internal  policies  contribute  to  this  ability.  Taligent's  investors  and  part¬ 
ners  must  cultivate  a  trust  relationship  with  Taligent  while  they  also  compete  with 
each  other.  Taligent's  workforce  will  collaborate  closely  with  a  respective  partner 
in  either  the  shared  domain  or  various  proprietary  domains.  For  Taligent  to  pro¬ 
ceed,  it  must  scrupulously  maintain  the  confidentiality  of  the  information  shared 
by  its  partners.  No  single  set  of  procedures  could  cover  all  the  conditions  which 
arise  in  unexpected  ways.  The  VE's  solution  is  to  provide  leadership  by  example 
from  above.  A  strong,  ethical  tone  is  set  by  the  senior  management  and  permeates 
the  corporate  culture  which  is  unique. 

We  were  not  able  to  gather  anecdotes  to  illustrate  the  practice.  But  numerous 
discussions  with  the  sponsors  underscored  how  prominent  and  visible  this  feature 
is  in  the  corporate  culture.  It  greatly  eases  the  potential  for  mistrust  and  allows 
focus  on  the  mission. 


Fetru^ry  IS,  1991 


99 


Part  1.  Metrics  Handbook 


4.3.9  Recent  Events 


(Events  since  the  case  studies  underscore  the  fact  that  agility  in  one  dimension  is  no  guarantee  in  another.  A 
surprising  number  of  the  example  best  practices  have  failed.) 


The  best  prartices  studies  are  only  two  years  old,  but  already  major  changes 
have  occuired.  It  is  illustrative  to  note  that  the  agility  we  discovered  was  not  ade- 
quate  to  address  the  major  changes  that  occurred.  The  change  that  actually  took 
place  differed  from  that  targeted  by  the  recorded  agility. 

4The  railroad  s  competitors  were  not  so  successful  improving  their  own  territory. 
So  they  have  sought  to  grow  stockholder  value  by  acquiring  other  railroads.  This 
has  forced  our  company  to  follow  suit.  The  rules  of  the  game  changed. 

4The  division  of  Westinghouse  we  surveyed  was  apparently  unexpectedly 
acquired  by  Northrop  Grumman  and  its  supply  chain  practices  are  turning  more 
conventional  as  it  merges. 


4Costs  in  the  airline  business  have  changed  and  threatening  mega-mergers  have 
appeared.  Labor  costs  have  forced  our  surveyed  company  to  abandon  the 
improvement  we  tracked. 


4The  shipyard  we  cited  competes  commercially  with  international  firms  and  is 
hampered  by  exchange  rates.  Losses  on  the  first  commercial  effort  are  high,  and 
more  work  has  not  been  attracted. 

^The  internet  radically  changed  the  market  for  operating  systems.  Many  of  the 
fundamental  assumptions  of  Taligent  no  longer  fit.  Taligent  has  been  dissolved. 
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5  Modeling  bv  Coinmunicative  Acts 

[The  metrics  depend  on  breaking  Reference  Model  entries  down  further  into  communicative  acts.  An  introduc¬ 
tion  to  communicative  acts  is  given  in  this  section.] 

In  addition  to  the  Reference  Model,  the  metrics  depend  on  a  few  fundamental 
foundations,  one  being  the  use  of  a  canonical  decomposition  of  processes.  Such  a 
decomposition  is  required  because  we  look  at  the  structure  of  processes  rather 
than  the  details  of  their  content  and  meaning.  Taking  this  approach  both  high¬ 
lights  the  dynamic  couplings  of  interest  within  the  VE  and  avoids  the  comparative¬ 
ly  high  cost  of  semantic  (meaning-based)  modeling. 

But  what  decomposition  to  use?  The  bewildering  variety  of  process  modeling 
approaches  is  only  an  indication  of  the  variety  of  theoretical  approaches  we  could 
take.  One  goal  of  the  project  was  discover  the  best  approach. 

We  settled  on  one  that  is  close  enough  to  the  mainstream  that  a  great  body  of 
existing  science  could  be  inherited.  On  the  other  hand,  the  approach  is  still  under 
development  and  freshly  incorporates  new  thinking  about  agency  and  effect. 
What's  still  being  uncovered  are  in  areas  unimportant  to  the  metrics  per  se,  but 
which  support  our  emerging  work  in  soft  modeling. 

5.1  The  Emergent  Systems  Influence 

|One  reason  for  communicative  acts  is  to  exploit  emergent  behavior,  such  as  that  exploited  by  simulations,  or 
as  appears  with  autonomous  agents.) 

The  goal  of  our  project  was  to  help  decisionmakers  design  agile  enterprise  sys¬ 
tems.  In  the  steady  state,  a  strategic  planner  knows  what  there  is  to  work  with  and 
what  has  to  be  done,  together  with  other  constraints.  But  the  agility  space  is  dif¬ 
ferent.  One  doesn't  know  what  all  the  threats  or  opportunities  are,  what  has  to  be 
done. 

One  can  determine  only  some  general  features  of  what  to  plan  for  in  the  future. 
So  how  does  one  design  systems  to  respond  to  unknown  situations?  The  answer 
is  often  to  design  systems  that  are  self-adapting,  that  respond  to  major  change  per¬ 
haps  without  even  seeing  it  as  such. 

Our  immediate  goal  is  to  reveal  metrics.  But  we  know  that  metrics  are  only  a 
starting  point.  Planners  will  want  to  not  only  know  how  agile  a  process/system  is, 
but  also  how  to  improve  it.  It's  only  responsible  of  us  to  choose  a  representation 
that  supports  this  need. 

Breaking  things  down  by  behavior  defines  agents  in  a  way  that  agent  systems 
theorists  can  directly  use  to  model,  predict  and  validate  emergent  behavior.  Emer¬ 
gent  behavior  in  this  context  is  behavior  that  the  system  automatically  assumes  be¬ 
cause  of  the  way  it  is  constituted.  The  extent  to  which  it  adapts,  the  cost  of 
adaptation  (extended  from  our  metrics)  and  whether  the  result  is  desirable  or  not 
are  all  results  for  which  we  are  laying  groundwork. 

)  Key  concepts  are: 

4 Emergent  behavior  as  the  adaptive  mechanism  which  constitutes  agility 
4Agents  as  the  units  which  exhibit  this  behavior.  For  our  purposes,  an  agent  is 
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something,  usually  someone,  who  does  work.  We  define  what  work  is  of  interest 
through  the  Reference  Model 

^Speech  acts,  or  Communicative  acts,  which  is  the  exchange  of  information  that 
allows  agents  to  collaborate 

Breaking  processes,  in  particular  process  cells  of  the  Reference  Model,  into 
speech  acts  is  key  to  identifying  and  evaluating  the  adaptability  of  the  enterprise. 

5.2  The  Need  for  Federatable  Executables 

(We  think  that  the  approach  could  in  the  future  support  self-organizing  enterprise  integration  strategies.] 

Regardless  of  whether  one  invests  in  the  emergent  systems  paradigm,  impor¬ 
tant  planning  and  control  systems  are  computerized.  It  seldom  occurs  that  all  of 
an  enterprise's  knowledge,  models  and  code  are  well  integrated.  This  becomes  less 
true  as  business  models  involving  many  partners  become  more  useful,  as  in  an  ag¬ 
ile  supply  chain.  The  state  of  integration  reaches  a  disastrous  state  in  the  Agile  Vir¬ 
tual  Enterprise. 

What  the  AVE  needs  is  a  collection  of  methods  and  tools  which  will  allow  it  to 
quickly  and  cheaply  federate  systems  and  knowledge  among  players  regardless  of 
whether  there  are  appropriate  standards  in  use.  Developing  general  federating 
principles  for  the  AVE  is  well  outside  of  the  scope  of  the  project;  however,  history 
shows  that  when  a  relationship  is  formed,  and  collaboration  is  desired,  metrics 
form  the  basis  for  framing  that  collaboration.  Integration  is  only  needed  to  support 
collaborative  goals.  Thus,  there  is  an  intimate  relationship  between  metrics  and  in¬ 
tegrating  infrastructure. 

We  need  to  be  sensitive  to  these  issues;  we  cannot  simply  devise  a  strategy  in 
ignorance  of  its  context  if  it  is  becomes  useful.  Our  focus  on  speech  acts  supports 
the  most  promising  approach  to  this  federation  problem.  The  approach  identifies 
the  agents  and  certain  (epistemological  and  ontological)  principles  of  how  they 
communicate.  Awareness  of  the  context  which  other  agents  use  allows  an  agent  to 
adapt  its  communicative  act  appropriately  to  effect  federation. 

Others  feel  this  way;  this  speech  act  approach  forms  the  basis  of  the  Knowledge 
Query  and  Manipulation  Language  (KQML)  resulting  from  significant  work  in  multi¬ 
agent  systems  under  the  DARPA-sponsored  Knowledge  Sharing  Initiative. 

5.3  Multiple  Representations 

(Even  within  the  metrics  approach,  we  support  a  version  of  self-organizing  integration  through  federation  of  our 
own  internal  models.] 

Similarly,  we  need  to  practice  federation  within  the  enterprise's  normal  repre¬ 
sentations,  because  users  have  different  needs  and  want  different  presentations. 
Users  in  this  case  may  be  humans  who  want  to  see  and  understand,  humans  who 
iwant  to  relay  information  to  an  external  analysis,  or  applications  which  directly  ac¬ 
cess  the  format. 

There  is  a  need  for  four  representations: 
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Tabular  (or  field  or  spreadsheet)  representation:  WeVe  found  this  type  of  rep* 
resentation  to  be  the  most  accessible  to  non-professional  modelers,  our  target 
audience.  In  part,  this  is  because  it's  a  necessarily  two-dimensional,  ordered 
means  of  entering  and  recovering  data  elements  common  to  paper  and  screen 
layouts.  The  familiarity  is  because  this  is  how  databases  deal  with  information: 
each  row,  (the  way  we  present  it)  is  an  instance,  each  column  is  a  data  type.  The 
accessibility  is  because  each  entry  is  distinctly  bounded  and  cleanly  defined.  The 
cells  in  our  spreadsheet  view  map  from  our  AVE  Reference  Model. 

^A  Graphical  representation:  However,  when  looking  at  a  process  as  a  system, 
one  needs  a  representation  that  conveys  the  whole  picture  and  key  relationships 
at  once.  We've  chosen  a  specific  graphical  representation  called  a  Dooley  Graph 
which  is  described  in  some  detail  below.  It  is  not  a  graphic  logical  notation  for 
robust  modeling,  as  one  would  find  within  a  modeling  methodology.  Instead,  it  is 
a  simple  presentation  (nodes  and  arrow)  which  reveals  the  structural  elements  of 
interest  to  us  regarding  how  the  agents  are  coupled. 

^A  Parametric  representation:  This  consists  of  numbers  and  arithmetic  relation¬ 
ships  among  them.  It  is  essential  that  this  model  exist.  We  believe  that  few  users 
will  consider  agility  in  a  vacuum.  They  will  be  dealing  with  the  costs  and  benefits 
of  agility  within  the  context  of  other  business  factors,  and  the  common  way  for 
these  to  be  balanced  is  as  numbers  in  parametric  models,  usually  as  dollars  in 
spreadsheets.  If  we  cannot  present  a  format  for  this  process,  the  agility  metrics 
cannot  enter  the  mainstream. 

^A  Sentential  representation:  While  many  of  our  initial  users  will  deal  only  with 
the  parametric  model,  a  whole  new  class  of  planning  tools  are  emerging.  These 
tools  understand  much  of  the  underlying  logic  of  processes  and  systems,  differ¬ 
ing  from  the  tools  which  work  from  mere  numbers.  Formal  statements,  or  sen¬ 
tences  are  required,  statements  about  processes  or  related  dynamics.  The  nature 
of  this  representation,  its  capabilities,  and  possible  future  uses  are  the  topic  of 
the  part  on  Soft  Modeling. 

These  are  not  just  different  views  of  the  same  data;  they  are  different  models. 
Some  algorithmic  transformation  is  required.  The  sentential  is  the  most  complete, 
while  our  parametric  model  has  the  least  information,  containing  only  our  specific 
arithmetic  results.  These  four  models  would  ideally  be  federated  within  an  agility 
planning  tool. 

Federation  would  allow  a  user  to  explore  options  in  any  representation  and  see 
the  effects  in  another.  The  likeliest  of  these  scenarios  would  be  for  a  planner  to 
enter  a  collection  of  real  or  possible  processes  in  the  tabular  form,  seeing  the  num¬ 
bers  which  indicate  agility  of  each  process  and  the  total  system.  Not  liking  the 
number,  the  planner  may  choose  to  look  at  the  graphic  format  and  ask  what  chang¬ 
es  would  make  the  process  or  system  more  agile  (or  equally  agile  at  a  lower  cost). 
^The  tool  may  call  externally  using  the  sentential  format,  getting  back  results  which 
show  differing  graphs  and  their  respective  numbers. 

The  part  dealing  with  Tool  Strategies  explores  this  In  depth. 
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Tabular: 


Sentential:  S  »=«acts,  p  ,  t,  m,  <seeks,  Or,  Ot,  1>,  g,  1» 


Figure  5-1:Four  Different  Representations 


5.4  Formal  Foundations 

(Communicative  acts  helps  us  lay  a  rigorous  foundation.] 

Everything  we  do  has  to  have  a  foundation  that  is  rigorous.  One  reason  is  that 
we  simply  cannot  support  the  useful  agenda  that  we  lay  out  above.  Another  is  that 
business  planning  is  not  a  casual  affair.  Where  an  auditable  logic  chain  is  sought, 
we  should  be  able  to  deliver. 

Agility  is  a  radical  idea;  the  engineering  of  enterprises  to  be  agile  systems  In  a 
predictable  manner  is  even  more  so.  Conventional  foundations  can  only  take  us  so 
far.  We  cannot  afford  to  create  new  science,  so  a  strategy  was  taken  to  leverage 
solid  science  from  other  domains  Into  this  new  one  where  appropriate.  Some 
terms  and  binding  needed  to  be  developed. 

Among  the  insights  that  were  integrated,  one  is  central  to  the  method:  model¬ 
ing  processes  in  the  enterprise  as  conversations,  then  measuring  the  complexity  of 
the  resulting  structure. 

5.4.1  The  Conversation  Metaphor 

|The  approach  allows  us  to  see  processes  in  terms  of  conversations  of  communicative  acts.] 

Our  representation  utilizes  a  conversation  metaphor.  The  basic  idea  is  that  agil¬ 
ity  is  a  matter  of  dynamic  coupling.  How  processes  are  coupled  is  by  information 
transfer.  A  convenient  way  to  see  one  specific  information  transfer  is  to  view  it  as 
'an  utterance,  which  is  originated  by  a  single  agent  and  directed  at  one  or  more 
agents.  A  collection  of  related  utterances  is  a  conversation.  Each  process  in  the  en- 
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terprise  involves  a  conversation  which  reveals  its  information  structure,  the  dy¬ 
namics  of  how  it  is  coupled  internally  and  with  other  processes. 

There's  a  fairly  deep  epistemological  reason  why  this  approach  works  for  us, 
which  we  won't  examine  in  depth.  But  a  simple  explanation  is  that  we  are  interest¬ 
ed  in  the  dynamics  of  collaboration,  what  some  information  values  are  within  a 
complete  system.  By  defining  our  primitives  as  single  acts,  originating  from  single 
actors,  we  reveal  a  topology  of  the  collaboration  within  that  system. 

This  representation  has  a  number  of  benefits: 

^It  reveals  what  we  need,  requiring  the  minimum  (read:  lowest  cost)  data  collec¬ 
tion 

^It  can  be  directly  used  for  simulation,  each  actor  specification  being  expressible 
as  executable  code 

^As  a  result,  it  can  specify  and  predict  (some)  behavior  in  non-deterministic  sys¬ 
tems,  and  reveal  emergent  behavior 

^The  metaphor  is  intuitive  in  that  many  of  the  harder  processes  one  models  are 
business  processes;  here  conversations  map  literally  to  what  is  said. 

Its  primary  disadvantage  is  that  it  is  unfamiliar  to  business  analysts  and  plan¬ 
ners,  our  target  audience.  The  case  study  evaluates  the  costs  associated  with  this 
unfamiliarity. 

5.5  Background  of  Speech  Acts 

|A  few  words  on  some  background  and  related  definitions.) 

A  common  sense  view  of  a  simple  statement  is  that  it  contains  information  and 
is  either  true  or  false.  Much  has  been  built  around  this  idea  and  we  now  have  elab¬ 
orate  and  useful  notions  of  the  truth,  information  content  and  meaning  of  state¬ 
ments.  Generally,  the  approach  keeps  the  idea  of  statements  which  communicate 
information  separate  from  the  work  that  goes  on  at  either  end. 

This  is  seen  also  in  the  conventional  distinction  in  computer  science  between 
data  and  programs.  Data  is  information  that  is  often  shared  among  machines  and 
humans.  Programs  on  the  other  hand  are  relatively  immobile,  often  seen  as  black 
boxes. 

But  another  view  merges  the  two  classes.  An  utterance  by  someone  is  part  of  the 
work  that  is  being  done,  a  rather  significant  part  of  the  overall  work  if  the  activity 
is  highly  collaborative.  Formal  thinking  of  this  view  has  been  around  for  35  years 
or  so  (AUST621. 

This  idea  has  fortunately  been  elaborated  by  the  agent  community  which  began 
within  the  artificial  intelligence  community  and  since  has  flourished  while  gener¬ 
ally  A1  has  languished.  A  substantial  percentage  of  the  key  sponsorship  for  this 
work  was  by  the  Advanced  Research  Projects  Agency,  one  example  of  which  is 
^KQML,  as  we've  noted  |CL95l.  This  represents  a  decade  of  refinement  of  the  ideas. 
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Hereafter,  for  consistency,  we'll  use  the  term  utterance  where  we  have  also  used 
communicative  act,  and  statement.  A  coherent  collection  of  utterances  will  be  a 
conversation.  The  types  of  utterances  are  performatives. 

5.5.1  Relevance  to  Agility 

|A  smsll  section  on  communicstion  as  the  dynamic  coupling  which  some  define  as  agility.) 

Before  we  get  into  details,  let's  review  what  we  are  doing  and  why.  Agility  is  con- 
cerned  not  with  everything  that  occurs  in  an  enterprise.  It's  concerned  with  how 
things  are  coupled,  how  they  interact,  and  how  readily  that  coupling  can  respond 
m  a  beneficial  way.  In  this,  we  are  following  the  thinking  of  Ken  Preiss  IPGN96|. 

That  coupling  is  the  same,  if  we  are  careful,  as  the  set  of  utterances  among 
agents  within  an  enterprise.  The  Reference  Model  helps  us  with  this  care.  By 
adopting  the  foundations  of  agent  theory,  we'll  be  able  to  have  a  formal  basis  for 
looking  at  the  nature  of  the  coupling. 

5.6  A  Candidate  Dynamics  of  Speech  Acts 

(The  essentials  of  speech  acts  are  given  here.) 

(Information  in  this  section  was  contributed  by  Van  Parunak  of  the  Industrial 
Technology  Institute.) 

Utterances  are  of  different  types  and  this  is  important.  The  type  of  utterance 
that  says: 

“Can  you  paint  a  widget  tomorrow?" 

is  different  from 

“Painting  a  widget  tomorrow  will  cost  eight  dollars." 

and 

“I  painted  your  widget." 

The  nature  of  the  what  is  intended  is  different,  and  what  is  required  as  following 
utterances  changes. 

If  the  goal  is  to  paint  widgets,  then  the  first  utterance,  the  query,  requires  a  re¬ 
sponse,  which  implies  a  different  type  of  coupling  than  the  others  which  are  more 
informational.  The  different  types  of  utterances  are  called  performatives,  meaning 
loosely  the  different  forms  of  performing  work. 

Many  recent  process  modeling  methods  and  indexing  strategies  use  this  tech¬ 
nique  of  defining  performatives.  Also,  much  of  the  work  in  the  Collaboration  The¬ 
ory  area,  such  as  the  work  at  MIT  [MCLP93|  is  close  in  its  philosophy. 

Major  differences  are  in  how  many  performatives  there  are,  and  what  consti¬ 
tutes  a  use^l  primitive  set.  KQML  (FFMM94j  defines  42  performatives,  but  there 
^has  been  discussion  that  many  are  ambiguous  and  redundant.  Cohen  {CL95|  sug¬ 
gests  a  much  simpler  approach  which  introduces  the  notion  of  a  hierarchy  and 
keeps  performatives  few  and  atomic.  We've  adopted  this  approach. 
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5.6.1  Speech  Acts 

[The  specific  types,  performatives,  of  speech  (communicative)  acts  are  defined.) 

The  figure  shows  the  basic  types.  All  acts  are  presumed  to  be  attempts  to  ac¬ 
complish  something,  so  the  top  of  the  hierarchy  is  attempt.  All  acts  are  subtypes 
of  attempt. 


Act  Speech  Act  (Attempt)  Solicit 


Assert 

Non-Speech  Act  (Do) 

Request 


Figure  5-2:A  Sparse  Set  of  Performatives 


Question 


Inform 


Commit 


Refuse 

Ship 


Pay 


^Solicit:  A  solicit  is  an  attempt  by  a  sender  to  achieve  mutual  benefit  with  an 
addressee.  The  sender  wants  the  addressee  to  do  something  which  the  sender 
wants  done.  The  sender  defines  both  what  is  done  and  what  constitutes  comple¬ 
tion. 

^Question:  A  question  solicits  the  addressee  to  inform  (see  below)  the 
sender  of  some  proposition. 

^Request:  A  request  solicits  the  addressee  to  commit  (see  below)  to  the 
sender  concerning  some  action. 

^Assert:  An  assert  is  an  attempt  by  a  sender  to  achieve  mutual  benefit  with  an 
addressee.  The  sender  wants  the  addressee  to  believe  the  asserted  statement. 
^Inform:  An  inform  Is  an  assert  (an  attempt)  to  get  the  addressee  to  believe 

the  content. 

^Commit:  A  commit  is  an  assert  that  the  sender  has  adopted  a  persistent 
goal  to  achieve  something  relative  to  the  addressee's  desires. 

^Refuse:  A  refuse  is  an  assert  that  the  sender  has  not  adopted  a  persistent 
goal  to  achieve  something  relative  to  the  addressee's  desires. 
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There  is  some  work  done  which  is  not  associated  with  speech.  In  the  general 
case,  these  performatives  are  many,  and  difficult  to  define.  Fortunately  for  us,  our 
strategy  makes  this  part  of  the  problem  trivial. 

Our  scope  deals  with  for-profit  business  enterprises;  we  assume  that  every  part¬ 
ner  and  every  process  adds  value  to  a  goal  of  creating  wealth.  What  is  important 
is  that  each  process  has  a  cost  and  it  adds  value,  that's  all.  So  we  add  two  non¬ 
speech  acts  to  our  performative  vocabulary. 

4Ship:  A  ship  is  the  transfer  of  value  sender  has  (perhaps  partially)  executed 
some  portion  of  the  action  promised  in  an  earlier  commit  and  a  request  that  the 
addressee  pay. 

^Pay:  A  pay  is  the  transfer  of  wealth  between  the  sender  and  the  addressee.  In 
some  contexts,  implies  an  assert  that  the  addressee  agrees  that  the  sender  has 
(perhaps  partially)  executed  the  action  promised  in  an  earlier  commit. 

Needless  to  say,  we  can  come  up  with  innumerable  combinations  and  special 
cases  of  these  performatives,  as  we  in  fact  do  in  everyday  life.  For  instance,  there 
is  could  be  a  type  parallel  to  assert  called  command  where  the  control  over  the 
content  is  with  the  addressee's  desires  rather  than  the  sender. 

Or  one  could,  for  example,  construct  something  called  propose,  composed  of  an 
inform  of  the  sender's  willingness  to  take  some  action  on  specified  terms  with  a 
request  that  the  addresses  request  this  action  of  the  sender.  But  for  the  metrics,  we 
insist  on  this  atomic  breakdown  because  it  is  simple,  complete,  and  gives  us  a  neu¬ 
tral  basis  for  comparisons  among  processes  and  systems. 

However,  we  note  here  that  these  atomic  performatives  can  be  composed  to 
theoretically  map  to  any  formally  based  modeling  method  based  on  information 
exchange.  We  expect  that  within  certain  applications  the  addition  of  composed 
items  may  emerge  as  either  an  aid  for  interpreting,  or  as  a  path  to  mapping  from 
established  models. 

5.6.2  Sequential  Relations 

[The  rules  for  combining  acts.  These  are  used  later  in  calculating  the  Dooley  Graph.) 

Another  component  of  the  theory  deals  with  the  sequential  relationships  among 
performatives  that  constitute  a  conversation.  For  some  time,  reply  and  resolution 
have  been  considered  the  basis  of  repartee  (L0NG761. 

Van  Parunak  (PARU96aj(PARU96l(PARU96c]  proposes  that  two  others,  response 
and  completion,  will  also  be  useful.  The  four  together  establish  relationships 
among  the  agents  which  we  will  exploit  both  in  creating  a  graphical  representa¬ 
tion,  and  in  calculating  the  metrics.  Each  of  the  four  is  discussed  below,  the  order 
is  from  most  connected  to  least. 


5.6.2. 1  Respond 

It  follows  from  the  definition  of  a  conversation  that  each  utterance,  except  the 
first,  responds  to  a  previous  one.  The  response  linkage  is  the  fundamental  binding 
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which  constitutes  a  conversation  in  the  larger  sense;  this  also  is  true  in  the  more 
limited  sense  we  use  of  a  conversation  bounded  as  a  process  within  an  enterprise. 

An  utterance  (2)  responds  to  another  (1)  if: 

4(1)  was  received, 

4(1 )  caused  (2),  (further  investigation  of  cause  being  taken  up  in  our  work  on  Soft 
Mathematics),  and 

4There  is  no  other  prior  series  of  utterances  which  (could  have)  caused  (2). 
Essentially  this  means  that  (1)  was  the  first  utterance  to  be  received  that  could 
have  caused  (2). 

It  is  necessary  that  the  utterance  one  responds  to  be  addressed  to  it;  but  it  is 
not  necessary  that  the  response  go  back  along  the  same  path.  The  response  could, 
and  often  does,  involve  another  party.  So  if  A  sent  an  utterance  to  B,  B  could  re¬ 
spond  to  that  by  sending  an  utterance  to  C.  But  B  couldn't  respond  if  A's  utterance 
had  been  to  C.  A  single  utterance  can  respond  to  multiple  preceding  utterances. 

5. 6.2.2  Reply 

Reply  is  different  than  respond.  Not  every  utterance  after  the  first  is  a  response. 
Respond  denotes  more  of  a  trigger,  while  reply  concerns  the  answer  utterance  that 
is  triggered.  An  utterance  (2)  is  a  reply  to  another  (1)  if: 

4(1)  was  received 

40ne  of  the  addressees  of  (1)  is  the  sender  of  (2) 

4The  addressee  of  (2)  is  the  sender  of  (1) 

4(2)  is  the  most  recent  response  from  that  addressee  to  (1).  This  condition  simply 
means  that  the  most  direa  responses  are  the  only  one  we  recognize,  not 
responses  through  intermediaries. 

It  is  possible  for  replies  to  differ  from  responses.  A  could  send  an  utterance  (1) 
to  B  and  C;  then  B  could  send  an  utterance  to  A.  In  this  case  (2)  could  be  both  a 
reply  and  a  response  to  (1).  Then  C  could  send  an  utterance  (3)  to  A  that  is  trig¬ 
gered  by  (2).  In  this  case,  (3)  is  a  response  to  (2)  and  a  reply  to  (1). 

5.6.2.3  Resolve 

Resolve  is  a  subset  of  reply.  Some  utterances  presume  a  reply  in  the  same  way 
that  in  normal  speech  a  question  presumes  an  answer.  This  is  a  result  of  an  utter¬ 
ance  controlling  some  part  of  the  conversation,  and  the  resolve  breaks  down  or 
completes  that  temporary  control. 

A  solicit  not  only  communicates  a  mental  state,  but  also  proposes  rules  for  how 
the  next  steps  of  the  conversation  will  proceed.  A  reply  can  accept  or  ignore  those 
rules. 

^  The  sender  of  these  kinds  of  utterances  establishes  the  ground  rules  for  the  res¬ 
olution  and  thence  directs  to  some  extent  the  flow  of  collaborative  information. 
Since  we  presume  that  our  conversation  is  a  process  which  is  engineered  to  ac- 
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complish  a  certain  task,  this  temporal  control  is  important.  Presented  with  this 
type  of  control,  an  addressee  can  defer  resolution,  say  in  order  to  discover  more 
about  the  context  or  other  agents.  Tracking  resolution  helps  illuminate  these  dy¬ 
namics. 

We'll  revisit  this  below. 

Only  some  of  our  performatives  can  be  resolved: 

4An  appropriate  inform  resolves  a  question,  and 

^An  appropriate  refuse,  commit,  or  non-speech  act  {ship,  pay)  resolves  a  request. 

Note  that  if  an  utterance  has  several  addressees,  it  can  have  that  many  resolu¬ 
tions. 

It  also  should  be  noted  here  that  the  whole  theory  is  still  being  refined,  and 
where  new  uses  and  context  are  discovered,  changes  may  be  made.  For  instance, 
it  may  be  useful  in  modeling  soft  processes  (those  governed  by  social/psychologi¬ 
cal  laws)  to  introduce  new  relations  which  track  how  the  addressee  chooses  to 
deal  with  this  imposed  control.  What  strategy  is  used  and  why  (assent,  defer,  ig¬ 
nore,  assert)  may  be  important  as  the  scope  of  the  metrics  grows  (see  second  order 
and  soft  modeling).  But  this  is  sufficient  for  the  scope  of  the  project. 

5.6.2.4  Complete 

Completion  is  similar  to  resolve  in  a  way.  Where  the  resolve  mechanism  cap¬ 
tures  how  the  conversation  is  controlled,  the  complete  mechanism  tracks  control 
over  the  actual  work  which  is  the  point  of  the  conversation  (process). 

When  one  agent  commits  to  do  something,  it  is  an  important  event  in  the  con¬ 
versation.  It's  the  work  that  gets  done  within  the  bounds  of  the  players  that  we've 
constrained  in  our  reference  model.  Details  of  that  work  don't  show  themselves  in 
the  conversation,  but  how  the  conversation  exerts  control  over  the  work  does. 

Only  commits  can  be  completed.  When  a  party  commits,  they  assume  certain 
things  about  the  environment,  which  is  another  way  that  constraints  are  com¬ 
posed  over  the  conversation.  But  as  we've  noted  this  time,  the  target  Is  not  the 
form  of  the  conversation,  but  the  nature  of  the  work. 

A  commit  can  be  completed  by  any  act. 

Resolve  and  complete  are  important  to  us  because  they  capture  the  two  meth¬ 
ods  by  which  agents  control  the  conversation  (process)  toward  a  goal.  The  com¬ 
plexity  of  those  control  mechanisms  relates  to  the  process's  adaptability,  hence  its 
agility. 

5.6.3  An  Example 

lAn  example  of  a  process  to  speech  act  model  is  given.  The  Dooley  Graph  is  introduced.) 

}  Consider  the  table  below.  This  shows  a  simple  process  at  the  level  of  complexity 
we'll  find  In  a  cell  of  our  Reference  Model,  at  the  same  level  as  the  example  of  the 
overview.  The  process  modeled  is  simple:  A  prime  contractor  (A)  has  suppliers  (B, 
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C  and  D);  the  prime  needs  50  widgets  by  next  Thursday.  We  model  the  process  by 
a  specific  instance  which  has  all  of  the  features  of  interest.  The  prime  advertises, 
gets  and  commits  to  less  than  what  it  wants;  changes  its  mind  when  it  discovers 
that  it  can  get  what  it  wants;  and  ends  up  not  getting  what  it  wants  so  has  to  take 
corrective  action.  Finally,  it  pays. 
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Please  send  me  50  widgets  at  your  catalog 
price  by  next  Thursday 
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Are  you  bidding  on  A’s  RFQ? 
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Inform 
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How  about  40  widgets  at  catalog  price  by 
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Please  send  me  40  widgets  at  catalog  price 
by  next  Friday 
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1  plan  to  send  you  40  widgets  at  catalog 
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Table  5-1:  Breakdown  of  an  Example  Process 
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We  would  have  selected  this  instance  of  the  process  to  capture  all  of  the  impor¬ 
tant  features  of  the  process  that  bear  on  the  agility  analysis  of  interest.  Suppose 
that  the  type  of  agility  we're  evaluating  is  the  ability  to  uncommit  from  one  suppli¬ 
er  when  a  more  adequate  one  appears. 

There  would  be  one  conversation  like  this  for  each  cell  of  the  Reference  Model, 
possibly  different  conversations  for  differing  strategies  or  agility-defined  condi¬ 
tions  of  change. 

The  table  has  a  column  for  each  of  the  sequential  relations:  respond,  reply,  re¬ 
solve  and  complete.  Each  row  in  the  table  is  a  specific  utterance;  it's  one  and  only 
one  of  the  performatives. 

Note  how  each  relation  works.  Respond  is  pretty  intuitive.  Reply  is  pretty  much 
the  same  as  respond  in  most  cases.  But  see  utterance  4  where  we've  created  a  sit¬ 
uation  where  it's  different.  B  doesn't  like  to  compete  with  C  because  they  know 
they  are  lying  cheating  scum,  so  B  asks  C  if  they  are  bidding  and  gets  an  affirmative. 
So  B  tells  the  prime  in  4  that  they  are  no  bidding.  Utterance  4  was  triggered  by  {re¬ 
sponds  to)  3,  but  is  a  response  to  1 .  It  also  resolves  1 ,  since  that's  the  end  of  party 
B  for  now. 

The  rest  of  the  relationships  are  pretty  straightforward.  The  figure  shows  the 
overlap  of  the  relationships  for  the  example. 


Figure  5-3:The  Example’s  Combined  Relationships 


D 


14 


There  are  several  ways  of  graphically  representing  the  example  conversation. 
We  want  our  graphical  representation  to  reveal  the  specific  complexity  of  the  con- 
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versation  in  terms  of  the  features  that  are  costly  to  both  execute  and  adapt.  This 
graphical  form  is  called  a  Dooley  Graph,  after  the  person  who  first  described  it. 

To  introd  uce  Dooley  Graphs,  we  suggest  the  idea  of  states.  In  this  view,  all  of 
the  players  in  the  enterprise  (A,  B,  C  and  D)  collectively  form  a  state  machine.  Wi- 
nograd  and  Flores  {WF88|  developed  the  idea  of  a  state  machine  that  would  use 
performatives  of  the  type  described  above.  A  version  of  their  proposal  adjusted  to 
Parunak's  formalized  performatives  is  shown  below.  fThe  Flores  version  of  this  has 


Figure  5-4:Winogracl/Flores  Model  with  Formalized  Performatives 


been  successfully  commercialized  by  Action  Technologies,  and  has  been  validated 
in  useful  business  contexts). 

A  Dooley  Graph  combines  the  qualities  of  states  and  utterances  into  one  repre¬ 
sentation,  showing  both  the  work  to  support  or  move  the  conversation  (the  utter¬ 
ance  component)  and  the  work  effected  by  the  conversation  (the  state  component). 
It  is  a  simple  node  diagram,  consisting  of  nodes,  or  circles  and  links  or  arrows.  As 
a  hybrid,  speakers  can  occupy  more  than  one  node,  depending  on  the  state  of  the 
conversation.  The  Dooley  Graph  of  the  example  is  shown  below. 

See  how  Party  A  is  in  two  nodes.  AJ  is  the  role  A  plays  in  a  first  part  of  the  con¬ 
versation,  advertising  and  eventually  buying  widgets.  A2  is  a  second  part  of  the 
conversation  which  involves  the  commitment  for  an  incomplete  purchase  and  later 
cancellation  of  that  purchase.  The  process  of  which  this  is  an  instance  has  addition¬ 
al  complexity  to  be  able  to  support  these  additional  roles  of  A  and  C.  The  Dooley 
Graph  reveals  these  roles. 

^  The  method  for  creating  a  Dooley  Graph  is  not  intuitively  obvious;  it  is  the  only 
link  in  the  process  that  is  not,  so  we  have  created  a  prototype  application.  Pome¬ 
granate,  and  associated  class  libraries  to  do  so  automatically.  The  algorithm  itself 
is  described  in  Part  4. 
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Figure  5-5:The  Example’s  Dooley  Graph 
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6  Agile  Strategic  Planning 

[The  metrics'  approach  assumes  a  strategy  exists.  Since  there  are  no  known  tools  for  agility  planning,  we  created 
one  as  a  side  project.  It  is  described  here.) 

This  section  suggests  a  technique  to  feed  the  decomposition  of  the  enterprise 
into  processes  to  be  instanced  by  conversations.  It  is  the  result  of  work  performed 
by  the  AVE  Focus  Group,  Sandia  Labs,  and  the  Automation  and  Robotics  Research 
Institute 

Businesses  already  have  tools  to  support  strategic  planning  to  lower  cost,  in¬ 
crease  quality  and  decrease  time  to  market,  ^ility  is  another,  albeit  new  and  dif¬ 
ferent,  factor  that  pro-active  managers  will  use  in  designing  the  future  of  their 
organizations.  A  central  issue  is  how  to  create  a  strategy  that  has  the  most  bene¬ 
ficial  balance  of  agility  with  other  qualities.  Such  decisions  have  a  life  cycle.  And  at 
the  end  of  the  planning  life  cycle,  we  have  the  situation  where  a  strategy  has  been 
created,  and  the  questions  are  what  decisions  are  the  correct  ones  to  support  that 
strategy,  to  attain  the  desired  agility.  Our  metrics  support  this  end  of  strategic 
planning. 

But  there  is  an  earlier  phase,  where  strategic  ideas  are  generated  and  evaluated. 
This  section  deals  with  the  generation  of  novel,  advantageous  strategies  through 
strategic  brainstorming.  Other  methods  will  have  to  concern  themselves  with  the 
evaluation  of  those  ideas  through  simulations  and  associated  evaluation. 

The  method  we  propose  is  sensitive  to  agility.  Agility  is  important  in  situations 
where  change  is  assumed,  whether  that  change  is  something  that  merely  happens 
or  is  change  that  has  been  instigated  by  the  Virtual  Enterprise  (VE).  Most  strategic 
planning  methods  assume  continuity,  their  worth  depending  on  the  accuracy  of 
uniformly  extrapolating  from  prior,  real,  experience.  Again,  we  see  that  agility  is  a 
radical  new  idea;  new  methods  must  be  developed  to  support  it.  Although  the 
brainstorming  method  outlined  here  is  designed  to  accommodate  agility,  we  be¬ 
lieve  it  to  be  useful  for  generating  novel  strategies  across  the  board. 

There  are  two  key  ideas  in  the  brainstorming  method,  the  idea  of  memes  and 
the  associated  idea  of  underlying  perspectives  or  principles.  We’ll  briefly  introduce 
those  two  ideas,  immediately  below  and  in  Part  3.  We  suggest  that  these  ideas  be 
hosted  in  a  role  playing  activity,  because  that  is  a  well  established  productive  tech¬ 
nique  where  the  core  ideas  are  strong.  Finally,  we  add  certain  triggers  that  analysis 
of  the  Dooley  Graphs  shows 

6.1  Memes 

[The  brainstorming  method  depends  on  harnessing  irrepressible  trends  in  groups.  A  handy  way  to  describe 
these  trends  is  as  memes.  So  a  brief  introduction  to  memes  is  given.) 

Certain  patterns  in  the  environment  seem  to  pop  up  over  and  over  again.  Have 
you  ever  passed  someone  humming  a  tune  and  found  yourself  humming  it  all  day? 
These  things  spread  by  being  passed  from  host  to  host,  as  jokes  are  from  person 
to  person.  They  act  almost  like  viruses,  these  ideas,  pieces  of  information,  and 
memories,  spreading  and  replicating  almost  as  if  they  were  acting  intelligently. 
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Moreover,  they  adapt  as  conditions  warrant;  a  Chuck  Berry  guitar  riff  will  promul¬ 
gate  itself  in  dozens  of  transmuted  ways  in  successive  popular  music. 

And  there  are  ideas  that  take  on  a  life  of  their  own,  like  property  ownership,  civil 
liberty,  or  human  rights.  The  latter  two  are  modern  ideas,  and  the  idea  of  real  es¬ 
tate  ownership  (in  the  sense  that  one  can  sell  land  as  they  sell  an  object)  has  only 
a  somewhat  longer  pedigree.  It  is  hard  to  imagine  the  eons  of  human  thinking  that 
transpired  before  these  ideas  caught  on.  But  it  was  so. 

So  powerful  are  these  ideas  that  it  is  very  difficult  for  historians  to  get  a  perspec¬ 
tive  on  actions  and  motives  before  they  appeared.  What  is  taken  as  rational 
thought  itself  seems  to  change.  The  point  for  us  is  that  as  obvious  as  these  ideas 
are  today-or  perhaps  so  obvious  that  we  sometimes  ignore  them~it  would  have 
been  almost  impossible  to  predict  their  appearance,  understand  their  content,  and 
appreciate  the  resulting  changes  in  the  world. 

No  one  would  claim  that  ideas  like  these  are  themselves  intelligent  entities  in 
the  way  that  humans  are.  Nor  does  it  make  sense  to  see  the  passing  of  an  idea  from 
one  person  to  another  as  an  intelligent  act  on  the  part  of  the  idea  (as  opposed  to 
the  humans  involved).  But  when  viewed  at  a  high  level  in  aggregate,  intellectual 
tokens  (ideas,  musical  themes,  languages)  do  seem  to  act  in  some  ways  intelligent- 

iy- 

Such  ideas  act  intelligently  in  the  same  way  that  an  ant  colony  or  beehive,  when 
seen  collectively,  seems  to  act  intelligently.  The  intelligence  is  like  that  ascribed  to 
agents  of  disease,  the  behavior  of  which  is  studied  by  epidemiologists,  or  to  genes. 
Individual  varieties  of  genes  can  be  said  to  collectively  exhibit  intelligence,  using 
life  forms  merely  as  a  vector,  a  host  in  their  drive  to  maximize  benefit  to  them¬ 
selves.  Benefit  to  the  hosts  over  time  may  coincide  with  the  gene’s  interests,  or  it 
may  not. 

Much  of  modern  evolutionary  thinking  (that  of  constructive  evolution)  is  based 
on  this  idea  of  genes  as  autonomous,  fine-grained  agents  with  collective  intelli¬ 
gence,  intelligence  meaning  the  ability  to  adapt  to  enhance  certain  goals,  in  other 
words,  to  be  agile.  This  is  a  powerful  idea,  certain  genes  acting  agily  as  a  learning 
organization.  The  idea  is  so  useful  that  an  evolutionary  scientist,  Richard  Dawkins, 
extended  it  in  1976  IDAWK76j[DAWK96]  from  genetic  entities  (biology-based 
memory)  to  apply  to  intelligence-based  entities.  Such  entities  include  songs,  ideas, 
and  the  like  which  are  based  on  memory  in  the  mind  or  the  mind’s  external  stores 
(books,  records,  computer  memory...). 

Dawkins  coined  the  term  Meme  for  this  kind  of  self-replicating  entity.  This  coin¬ 
ing  exemplifies  the  idea  of  turning  the  conventional  relationship  of  (active)  actor 
and  (passive)  participant  on  its  head,  thus: 

“A  hen  is  just  an  egg’s  strategy  for  making  another  egg.” 

The  idea  of  memes  has  itself  become  a  powerful  meme,  and  the  idea  has  found 
|Wide  use  in  the  artificial  intelligence  community  and  in  studies  of  cognition  and 
complexity.  We  submit  the  concept  as  one  of  the  bases  for  this  structured  brain¬ 
storming  method. 
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A  more  detailed  discussion  of  memes  is  spread  through  Part  3. 

6.2  Relevance  to  Brainstorming 

[Why  memes  may  be  helpful  in  predicting  enterprise  agility.) 

In  particular,  we  want  to  understand  what  makes  a  meme  tick  sufficiently  well 
in  order  to  look  at  novel  future  alternatives.  By  understanding  what  makes  memes 
catch  on,  we  get  closer  to  understanding  the  general  shape  of  unexpected  change, 
at  least  those  changes  that  are  humanly  driven.  The  AVE  Focus  Group's  survey  in* 
dicated  that  these  are  the  most  important,  and  dangerous  to  businesses. 

When  we  get  to  tactical  agility,  we  consider  the  VE  as  a  collection  of  agents 
which  are  dynamically  coupled.  We  concern  ourselves  with  which  agents  are  the 
best  to  add  or  to  take  away  from  the  VE,  for  certain  agility  goals.  More  importantly, 
we  are  interested  in  understanding  and  engineering  the  coupling  that  dynamically 
binds  those  agents.  For  the  case  of  strategic  brainstorming,  we’ll  define  the  agents 
differently,  as  memes. 

If  we  are  brainstorming  a  Type  2  VE  --in  which  we  have  a  collection  of  memes 
(meaning  capabilities)  and  are  brainstorming  for  an  opportunity  in  which  to  use 
them-we’ll  want  to  understand  the  natural  tendencies  of  the  memes  and  the  log¬ 
ical  directions  in  which  they  will  go.  This  is  different  than  evaluating  core  compe¬ 
tencies  of  the  VE  in  a  static  manner  and  evaluating  opportunities;  instead,  you 
track  the  meme  equivalent.  The  result  is  as  if  you  were  seeing  how  the  existing 
core  competencies  naturally  want  to  evolve  and  were  looking  for  an  opportunity 
somewhere  on  that  track. 

For  brainstorming  a  Type  1  VE-in  which  we  create  a  hypothetical  opportunity 
and  then  brainstorm  for  the  correct  recipe  for  a  VE  which  will  suit  that  opportuni- 
ty-the  situation  becomes  more  complex  than  the  above  (Type  2  VE)  example  and 
also  more  Interesting.  Here,  you  want  to  develop  a  meme  aggregation  that  has  a 
natural  learning  path  which  will  take  It  In  the  direction  of  the  opportunity  and  that 
has  the  natural  ability  to  adjust  as  the  opportunity  adjusts.  The  situation  is  com¬ 
plex  because,  unlike  genetic  evolution,  you  have  some  freedom  to  choose  partners 
and  engineer  the  dynamic  coupling  among  them. 

A  few  characteristics  of  memes  are  important  to  AVE  brainstorming: 

^  Memes  can  be  categorized  according  to  their  domain  of  influence,  and  that 
decomposition  is  the  same  as  the  infrastructure  categorization  weVe  developed. 
Memes  associated  with  contraa  law  have  effect  only  In  that  domain;  similarly  in 
business  practices.  We  have  an  example  of  each,  A  Key  Difference:  The  Engineer¬ 
ing  Paradigm  and  The  Role  of  Common  Law. 

^Those  examples  show  another  characteristic  as  well,  that  memes  can  be 
grouped  into  higher  classes.  The  French  engineering  meme  concerned  with  busi¬ 
ness  practices  and  the  Code  meme  which  deals  with  legal  issues  both  are  part  of 
a  higher  level  class  of  memes,  at  some  level  a  meme-class.  In  this  French  engi¬ 
neering/code  case,  it’s  a  class  that  forces  a  centralized,  top-down  control  of  pro- 
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^The  more  robust  memes  settle  into  a  system  by  creating  a  balance  with  a  com- 
plernentary  meme,  creating  (or  following)  a  simple  symmetry.  In  our  example,  the 
English  engineering  meme  was  balanced  by  the  French  one;  the  common  law 
meme  opposed  by  the  code  law.  This  is  even  more  evident  at  the  meme-class 
level.  So  centralized  control  systems  are  opposed  in  a  system,  of,  say,  human 
society,  by  a  decentralized  control  system,  with  special  cases  appearing  in  law 
and  engineering. 

^We  submit  that  all  memes  (of  interest  to  the  AVE)  fall  under  a  few  basic  catego¬ 
ries  of  meme-class.  We’ll  present  the  four  basic  sets  of  meme-classes  in  the  sec¬ 
tion  below. 

^Identification  of  memes  in  a  system  is  an  art,  is  highly  subjective,  and  often  pro¬ 
duces  results  that  are  trivial  or  worse-complex  but  without  providing  insight.  It’s 
much  easier  to  start  with  a  meme-class  and  develop  or  discover  a  specific  meme 
than  the  other  way  around. 

To  review:  the  idea  behind  our  metrics  is  that  by  understanding  the  processes 
in  AVEs,  we  can  measure  their  ability  to  adapt.  In  order  to  have  productive  brain¬ 
storming,  you  need  to  have  a  similar  understanding  of  processes,  how  they  adapt 
and  learn  in  your  system.  We  find  that  in  complex  systems  a  useful  way  of  under¬ 
standing  how  processes  or  agents  adapt  is  by  understanding  memes.  Furthermore, 
memes  themselves  have  underlying  principles,  which  we’ve  called  meme-classes.’ 
Useful  brainstorming  can  leverage  these  relationships  by  understanding  the  prin¬ 
ciples  underlying  the  memes  and  especially  the  fact  that  each  meme-class  has  a  du¬ 
al,  an  opposite  or  complement. 

6.3  Basic  Underlying  Principles/Controversies 

[We  describe  a  specific  taxonomy  of  memes  that  can  be  leveraged  for  agility  brainstorming.] 

Here  are  the  four  complementary  pairs  of  meme-classes  which  we  think  form  a 
complete  basis  for  memes  in  AVEs  and  which  can  be  used  to  create  a  structured 
controversy  method  for  brainstorming. 

A  disclaimer:  work  presented  in  other  chapters  has  a  more  thorough  formal  un¬ 
derpinning  than  here.  In  particular,  the  work  on  abstraction  that  is  novel  to  the 
metrics’  quantification  has  a  formal  basis  In  category  theory;  the  social  modeling 
re  ies  on  situation  theory;  and  the  infrastructure  and  communicative  act  parsing 
relies  on  long  established  organizational  and  information  theories. 

The  work  of  this  section  is  drawn  from  the  history  of  philosophy  and  from  some 
working  ideas  that  have  been  refined  through  empirical  work  by  the  AVE  Focus 
poup.  It  has  not,  so  far,  been  thoroughly  investigated.  But  we  commend  it  here 
because  it  seems  right,  it  works,  and  It  fills  a  need  in  agile  planning  for  which  there 
is  no  comparably  apt  technique. 

^  The  four  basic  controversies  are: 

^1.  Realism  versus  Phenomenalism 
^2.  Intrinsic  versus  Random  Order 
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^3,  Evolution  versus  Revolution 

^4.  Centralized  versus  Distributed  Control 

These  four  are  fully  symmetrical  (meaning  only  that  each  constitutes  a  comole- 
mentary  pair,  and  that  any  grouping  of  two  complement  the  remaining  two)  One 

Sn  of  n°rinXl«  Thi Symmetry  In  any  sufficiently  cleanbasic  dispo- 
sition  of  principles.  The  figure  shows  the  symmetries,  see  the  Soft  Mathematics 

Case  Study  for  a  French/English  Breakdown  and  Part  4  for  relevance  to  the  current 
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Figure  6-1  :Key  Meme-Classes 


problem  in  the  defense  world. 

The  first  two  pairs  of  meme-classes  are,  relatively  speaking,  more  fundamental 
^an  the  others.  They  deal  with  belief  systems,  with  how  people  believe  the  world 
works,  and  with  the  characteristics  of  the  fundamental  laws  of  nature.  The  second 
t^^are  underlying  ways  m  which  the  world  is  instanced,  how  it  exists,  using  those 

nn  dynamics  of  entities,  what  constitutes  being, 

and  the  second  and  fourth  reflect  controversies  about  the  dynamics  of  being  how 
systems  are  formed  and  interact,  ^ 

Each  of  the  four,  of  course,  denote  a  primitive  controversy,  that  is,  two  classes 
of  opposing  principles  around  which  many  types  of  ideas  can  be  formed  and  self- 
sustaining  as  memes.  The  first  listed  perspective  in  of  each  of  the  four  controver- 
sies  tend  to  go  together;  it  is  more  consistent,  for  instance,  for  someone  wh^ 
holds  realism  as  a  belief  to  also  believe  in  intrinsic  order,  evolution,  and  central¬ 
ized  control,  than  to  take  any  of  the  opposite  choices  along  with  any  of  these. 

Each  of  the  four  are  described  below.  It  may  be  of  interest  to  observe  that  thf* 
institutional  default  familiar  to  most  businesses  within  In  Western  civilization  (as 

I?n  J’’  K*  Judaism.  Christianity  and  Is¬ 

lam)  IS  based  on  the  first  choice  in  each  of  these  meme-classes  (realism,  intrinsic 
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6.3.1  Realism  versus  Phenomenalism 

IWhether  one  believes  in  a  universal  ciockmaker  of  some  kind  or  whether  the  clock  invents  itself.) 

Realism  is  illustrated  in  the  belief  that  a  tree  does  make  a  sound  in  the  woods 
even  if  unheard,  and,  more  generally,  that  the  woods  exist  independent  of  any 
need  for  human  existence.  The  world  is  real,  and  humans  experience  it.  Some  hu¬ 
mans,  because  of  individual  differences,  may  experience  it  differently,  but  reality 
is  out  there,  immutable.  The  notion  of  absolute  truth  follows  nicely  from  this. 
Truth  reflects  reality.  A  scientist  who  works  under  this  belief  believes  that  it  is  the 
role  of  a  scientist  to  discover  and  understand  the  truths  of  this  reality. 

Phenomenalism  is  the  group  of  beliefs  that  the  world  we  encounter  is  a  collec¬ 
tion  of  ordered  experiences.  Among  diverse  observers,  we  may  share  some  con¬ 
sensus  about  those  experiences  as  truth,  and  diverge  on  the  actual  nature  of  the 
world  in  other  ways.  Because  we  can  never  encounter  the  real  world,  only  sensory 
phenomena,  reality  as  an  independent  state  is  either  moot  or  unknowable.  A  sci¬ 
entist  working  under  this  system  strives  toward  inventing  new  ways  of  explaining 
phenomena  to  expand  the  class  of  shared  consensus.  How  the  scientist  communi¬ 
cates  and  explains  is  in  a  sense  more  important  here  than  what  is  explained. 

Each  of  these  views  contain  a  great  many  ideas,  some  of  which  have  a  very  long 
tradition.  Many  memes  are  spawned  and  take  on  their  own  lives,  strengthened  in 
an  important  way  by  its  complement.  Essentially  all  philosophical  discourse  uses 
memes  from  this  class. 

As  a  cogent  example,  suppose  you  are  brainstorming  early  in  the  game  of  our 
missile  AVE  example.  The  problem  you  are  examining  is 

“What  kind  of  product  strategy  is  best  for  us?" 

(We’ve  picked  a  mundane  example  because  of  its  illustrative  value  and  because 
of  the  leverage  we  get  by  keying  off  of  the  tactical  example.  After  addressing  this 
question,  the  missile  prime  might  brainstorm  on  how  best  to  support  that  strategy 
through  an  AVE.  A  simulation  would  validate/modify  the  approach,  resulting  in  the 
input  for  the  metrics. 

Realists  might  hold  that  the  way  that  the  world  works  is  set,  that  there  is  a  real, 
strong  idea  of  a  better  missile  design  and  a  less  good  one.  Their  brainstorming 
could  be  limited  to  the  context  of  that  reality,  trying  to  understand  and  negotiate 
it. 

Phenomenalists,  on  the  other  hand,  could  believe  that  a  missile  is  a  product, 
that  its  worth  is  in  meeting  customer  requirements,  and  that  there  is  no  basic  good 
design  outside  of  that  context.  Since  the  context  is  one  of  how  the  customer  sees 
the  world,  they  would  try  to  analyze  not  the  world  of  design,  but  the  world  of  the 
customer’s  predilections,  foibles,  concerns  and  inner  drives.  They  might  also  as¬ 
sume  that  the  customer’s  world  view  differs  fundamentally  from  the  prime’s. 

^6.3.2  Intrinsic  versus  Random  Order 

[Whether  the  behavior  of  the  clock  is  a  result  of  design  (extrinsic  or  intrinsic),  or  an  accident  of  nature.) 


Fekruary  15,  1997 


120 


Part  1.  Metrics  Handbook 


Some  hold  a  belief  that  the  world  Is  a  clockworks;  moreover,  that  it  is  a  single 
clockwork  system.  It  all  makes  sense  at  some  basic  level,  and  laws  at  work  in  one 
area  are  part  of  the  same  script  as  laws  that  work  in  another.  This  is  the  class  of 
views  that  are  under  the  belief  systems  of  intrinsic  order. 

A  contrasting  view  asserts  that  the  fact  that  we  have  scientific  laws  which  work 
does  not  Imply  that  the  world  has  a  single,  inner  logic.  Much  of  the  world  is  a  result 
of  acc/dents-many  of  the  physical  constants  for  instance.  So  while  weVe  been  in¬ 
ventive  enough  to  determine  some  local  order  in  the  cosmos,  underlying  it  all  is  a 
higher  order  of  chaotic  system.  (We’ve  used  the  term  random  order  here  for  histor¬ 
ical  reasons;  the  more  formal  term  would  be  chaotic  order  which  is  an  order.  Ran¬ 
domness  is  the  lack  of  order.) 

Our  missile  brainstormers,  if  they  are  taking  the  former  position  might  have 
views  about  economics,  politics,  and  society  that  presume  that  the  laws  of  design 
and  the  laws  of  business  and  the  laws  of  good  intention  are  all  congruent.  What’s 
good  for  Hughes  is  good  for  the  U.  S.  and  the  world.  Well  motivated  engineers  will 
make  better  products,  and  that’s  good  for  business,  good  for  the  prime.  In  the 
large,  the  system  works. 

Their  contrarians,  taking  the  other  option  (favoring  random  order),  would  hold 
that  what’s  good  for  the  prime  may  not  be  directly  and  completely  good  for  the 
customer  (the  U.  S.,  or  part  of  it  anyway);  also  that  there  are  many  areas  where 
competing  forces  are  at  work  between,  say,  best  design  and  corporate  goals. 
These  brainstormers  will  be  struggling  with  finding  the  correct  balance  of  these 
competing  forces-a  game  of  compromise. 

It  is  easy  to  see  how  the  two  groups  would  gravitate  to  radically  differing  prod¬ 
uct  strategies. 

6.3.3  Evolution  versus  Revolution 

[Whether  new  clocks  emerge  incrementally  or  in  major,  disruptive  spurts.) 

The  root  of  the  ideas  that  we  class  as  evolutionary  is  intuitively  understandable. 
Adherents  to  this  collection  of  ideas  would  hold  that  the  law  of  cause  and  effect  is 
apparent  in  every  process.  Sometimes  a  small  modification  in  cause  produces  wide 
modification  in  effect,  but  the  function  Is  still  apparent.  The  key  discriminator  of 
this  class  is  the  belief  that  any  outcome  can  be  predicted  if  enough  causal  factors 
are  known. 

The  opposite  hand  holds  the  belief  that  most  every  important  process  in  the 
world  has  characteristic  events  where  some  instability  is  reached  and  basic  causal 
conditions  are  changed.  The  important,  defining  element  of  the  process  is  not  the 
periods  of  relative  stability  between  punctuations  where  change  is  predictable  and 
gradual.  Instead,  what  matters  are  the  periods  where  many  Important  things 
change. 

^  In  our  imaginary  brainstorming  session,  the  evolutionists  might  concern  them¬ 
selves  with,  say,  a  product  that  will  provide  (a  considerable)  advantage  over  the 
competition,  by  better  understanding  and  exploiting  the  currently  applicable 
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rules.  The  revolutionaries  mighi:  focus  on  hov/  to  criiate  a  product  that  changes  the 
rules  to  their  advantage. 

6.3.4  Centralized  versus  Distributee  Control 

(Whether  someone  central  determines  tie  hoi  r,  or  we  reach  it  by  ccnsensus.j 

The  easiest  to  grasp  controversy  of  all  pits  the  paradigm  of  central  control 
against  that  of  decentralized  or  distributed  control.  This  (fourth)  class  and  the  pre¬ 
vious  (third)  class  are  not  controversies  about  how  the  world  works,  but  about  pre¬ 
ferred  ways  that  the  world  instances.  For  both  of  these,  this  and  the  prior  one 
there  are  many  examples  in  nature. 

In  animals,  a  centralized  control  system  is  a  mammal  with  a  brain  and  nervous 
sy^em.  A  decentralized  example  is  a  bee  colony.  In  U.  S.  government,  central  laws 
and  taxes  come  from  Washington,  decentralized  laws  and  taxes  from  innumerable 
state  capitals  and  town/city  halls. 

The  representative  of  central  thinking  will  look  to  a  product  that  leverages  the 
of  the  prime  as  a  prime,  so  that  the  prime  as  a  prime  is  made  stronger. 
The  decentralized-minded  brainstormer  may  seize  upon  a  more  peer-to-peer  AVE 
based  strategy  in  assembling  the  portfolio  of  product  options. 

6.4  Role  Playing 

(How  to  employ  the  controversies  described  above  in  a  structured  role  playing  context.) 

To  the  insights  noted  above,  we’ll  add  two  techniques.  The  first  is  tried  and  true, 
that  of  role  playing.  The  second  is  a  way  to  identify  process  tendencies  by  playing 
with  Dooley  Graphs.  Dooley  Graphs  were  discussed  in  the  previous  section. 

To  perform  your  structured  controversy  brainstorming,  you’ll  want  to  assemble 
a  small  group  of  people,  less  than  ten.  Ideally,  these  will  be  motivated,  alert  per¬ 
sons  from  diverse  backgrounds.  No  prior  skills  are  required  beyond  minimal  group 
skills,  but  it’s  obviously  necessary  that  they  be  familiar  with  whatever  domain  you 
are  brainstorming. 

You’ll  divide  these  people  into  two  groups  in  different  combinations  throughout 
the  exercise.  You  should  have  a  person  present  who  is  in  neither  group  and  acts 
as  recorder,  since  the  ideas  will  come  hot  and  heavy;  the  best  ideas  will  not  be  ap¬ 
parent  at  the  time  and  will  have  to  be  identified  on  refleaion.  How  the  group  is 
divided  is  important,  as  you’ll  see. 

You  should  also  have  a  facilitator  who  is  familiar  with  the  method  and  who  can 
set  up  the  problem,  This  person  will  also  guide  the  discussion  and  insure  that  play¬ 
ers  stay  in  character.  The  session  begins  by  the  facilitator  explaining  (in  about  30 
minutes)  three  things: 

^What  the  method  is  all  about,  at  the  highest  level.  The  discussion  on  memes 
'  can  be  omitted,  rather  focusing  on  the  idea  of  getting  new  perspectives  by  look¬ 
ing  at  situations  by  taking  a  new  basic  slant  in  a  structured  controversy. 

^What  the  four  basic  religious  principles  are  and  what  each  controversy  is  in 
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each  of  the  principles.  (Since  the  basic  positions  of  course  sometimes  do  indeed 
reflect  various  participants’  accustomed  religious  positions,  and  since  traditional 
guments  about  politics  and  religion,  per  se,  are  not  the  matters  of  most  inter¬ 
est  in  these  brainstorming  sessions,  we  suggest  that  the  facilitator  place  no 
mora  emphasis  on  such  terms  as  religion  or  God  or  atheism.  Instead  of  relying 
on  religious  and  political  terms,  the  facilitator  may  prefer  more  neutral  labels 
such  as  world  views  and  presuppositions.) 

iWhat  will  be  the  problem  of  the  day  be  around  which  the  group  will  be  brain¬ 
storming.  Examples; 

bulineSr'^^  upcoming  bid  to  stay  strong  in  the  missile 

What  new  markets  should  we  move  into  or  generate  that  leverajse 
our  strengths?” 

“What  kind  of  organization  should  we  become  (given  a  set  sce¬ 
nario)?" 

^^'^^*hing  (particular)  happened,  what  should  our  response 

problem  is  understood,  you  announce  that  we’ll  brainstorm  on  one  of 

Go  around  the  room  and  ask  each  person  to  iden¬ 
tify  their  default  position  on  that  issue.  You’ll  probably  start  with  the  simplest  is¬ 
sue,  centralized  versus  decentralized  control.  The  process  of  declaring  player? 
underlying  beliefs  is  a  little  tricky;  since  many  folks  haven’t  considered^ their  posi- 

be  naturally  of  one  bent  while  it  is  historically  dear 
that  they  are  in  the  other  camp.  That’s  okay.  Don’t  get  bogged  down  in  this  Take 
each  player  at  their  word.  Now,  ask  each  person  to  take  the  opposite  position  for 

tiic  g3rn6, 

Divide  the  group  up  as  evenly  as  possible  into  teams.  Ideally,  the  facilitator 

personalmes  involved,  and  is  able  to  level  the  teams  in  terms  of  argu¬ 
mentative  abiity.  The  effort  may  be  wasted  if  a  balanced  dialog  cannot  be  main¬ 
tained  and  unless  each  person  {as  well  as  each  team)  gets  their  say. 

The  game  proceeds  with  few  rules,  as  an  informal  debate.  Each  side  projects  the 
stat;^  problem  according  to  the  basic  assumptions  they  have  temporarily  adopt- 
.  :  J^^ture  of  advocating  each  position  should  include  arguing  against  the  do- 

sition  of  the  other  side.  What  creates  the  richest  possibilities  are  thfee  thingt^ 

^That  bright  people  are  using  perspectives  which  are  contrary  to  those  which 
they  otherwise  use  (outside  of  the  brainstorming  exercises) 

^That  they  actively  advocate  those  positions  (and  present  new  approaches  to 
products,  markets,  business  strategies...) 

^And  that  the  basic  issues  (on  which  the  positions  are  based)  are  defined  in  a 
way  that  mirrors  fundamental  controversies  both  with  their  natural  divisions  and 
in  ways  that  spawn  or  leverage  robust  memes. 
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In  conducting  the  exercise,  normal  group  management  skills  apply;  keep  the  fo¬ 
cus,  watch  for  dominating  speeches,  repetitive  exchanges,  and  dwelling  too  long 
on  a  topic.  You  should  arrange  to  have  an  out-of-character  signal,  so  that  a  person 
can  stop  to  ask  questions  if  needed,  but  otherwise  save  comments  and  complaints 
for  the  time  between  rounds.  Unless  the  signal  is  invoked,  all  players  are  presumed 
to  be  in  character. 

Each  round  should  only  last  30  minutes  or  so.  During  this  time,  it’s  often  the  case 
that  players  are  dying  to  take  the  other  side’s  position.  So  it’s  a  good  idea  to  give 
the  option  of  swapping  sides  for  the  subsequent  section.  Don’t  worry  about  peo¬ 
ple  stretching  their  assumptions  if  they  switch  back  to  their  natural  beliefs.  By  this 
time  things  will  usually  have  transcended  preconceived  constraints. 

Select  another  set  of  basic  issues,  choose  sides  again,  and  have  another  round, 
still  working  on  the  same  problem.  It  is  up  to  the  facilitator  to  select  a  basic  con¬ 
troversy  that  is  apt  for  the  problem  and  also  takes  advantage  of  some  of  the  issues 
raised  in  prior  rounds.  Players  tend  to  carry  over  gems  from  one  round  to  the  oth¬ 
er,  and  it’s  good  to  provide  a  different  medium  for  forming  the  thought. 

Only  spend  2  or  three  rounds  per  problem  statement.  You’ll  quickly  exhaust  the 
pool  of  spontaneous  insights.  Move  on  to  another  problem  statement.  If  you  have 
an  important  problem  that  you  really  need  addressed,  make  it  the  second  problem, 
having  the  first  be  a  warm-up.  But  don’t  make  that  first  one  trivial. 

The  whole  session  should  occupy  no  more  than  a  morning  or  an  afternoon.  The 
facilitator  should  not  be  any  player’s  supervisor,  and  the  session  should  not  be 
tape  recorded.  All  these  are  impediments. 

In  many  cases,  the  payoff  comes  in  a  second  session  In  a  few  days  or  a  week  with 
the  same  players  (no  more  than  two  substitutes).  This  time,  everyone  understands 
the  idea  of  playing  a  role,  and  you’ll  have  some  results  to  report  from  the  first 
round.  If  the  analysis  between  sessions  is  competent,  and  the  group  is  typical, 
they’ll  be  surprised  at  the  gems  that  can  be  found;  they  zip  by  so  fast  when  the 
discussion  is  underway,  they’re  not  noticed. 

This  general  method  was  created,  refined,  and  validated  by  the  AVE  Focus 
Group  and  has  been  used  elsewhere  with  positive  results.  In  all  cases,  the  topics 
were  not  narrowly  constrained  to  engineering  an  AVE. 

6.4.1  Future  Work:  the  Dooley  Graph  Link 

[Still  to  be  done  is  mapping  this  method  at  a  finer  level  of  granularity  so  that  the  role  playing  can  be  simulated 
by  agents.) 

We  envision  adding  another  dimension  of  the  structured  controversy  method: 
fleshing  out  the  structure  of  the  basic  controversies  which  have  been  defined  (Soft 
modeling),  and  focusing  in  on  engineering  of  agile  systems.  In  particular,  we  be¬ 
lieve  that  certain  configurations  in  an  organization  are  inherently  agile  (given  cer¬ 
tain  contexts),  and  that  those  configurations  create  recognizable  patterns  in  the 
resulting  Dooley  Graphs.  This  insight  extends  the  brainstorming  method  from  a 
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role-playing  game  to  utility  by  an  analyst  or  analytical  team  using  a  modeling  work¬ 
bench. 

This  is  work  to  be  done  by  others,  for  instance  as  a  followon  to  the  agility  re¬ 
search  of  the  Work  and  Technology  institute. 
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Part  2  is  targeted  toward  the  reader  who  is  interested  in  indepth  discussion  of  issues  which  surrounded  the 
project. 


7  Abstract 

In  this  part  are  collected  a  number  of  results  which  were  incidentally  reached. 
There  are  a  few  examples  given:  agility  as  competitive  weapon,  and  extremely  dy¬ 
namic  market  forces.  The  benefits  to  the  U.  S.  economy  and  the  defense  base  are 
reviewed. 

Projects  which  lead  up  to  the  metrics  project  are  summarized,  as  well  as  techni¬ 
cal  efforts  which  contributed  to  success  of  the  effort.  An  exhaustive  examination 
of  definitions  is  given:  The  virtual  enterprise,  the  agile  virtual  enterprise,  and  many 
issues  related  to  metric. 

We  compare  agility  to  many  other  efforts  which  benefit  an  enterprise,  and  other 
sponsored  agility  research. 

A  short  summary  of  the  approach  is  recounted  and  known  limits  are  reviewed. 
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8  Agility  Is  Different 

[A  case  is  made  that  agility  is  both  important  and  fundamentally  different  than  other  management  concerns.  Ex¬ 
amples  are  given  where  agility  (or  lack  of  it)  is  a  factor.  There's  an  example  of  an  instance  where  lean  is  not  agile. 
We  outline  steps  for  agility  thinking.] 

A  major  challenge  in  life  is  discriminating  what  is  changing  from  what  is  not. 
What's  new  is  that  not  only  is  the  rate  of  change  increasing  (changerate)  but  the 
things  that  change  are  changing.  It's  no  longer  sufficient  to  be  fast,  not  enough  to 
be  able  to  respond  nimbly  when  change  is  recognized.  Firms  need  to  engineer  the 
ability  to  respond  to  specific  types  of  change. 

When  Wang  Laboratories  invented  the  word  processor,  an  innovation  that 
quickly  created  a  billion-dollar  company,  shock  waves  hit  the  world’s  largest  type¬ 
writer  producer,  IBM.  IBM  had  dominated  the  typewriter  market  with  the  most 
preferred  products,  but  they  were  initially  unable  to  respond  to  Wang’s  innova¬ 
tion.  Wang  successfully  redefined  and  dominated  this  market  precisely  because 
they  took  advantage  of  change. 

Yet,  when  Wang’s  market  started  eroding  with  the  appearance  of  word  process¬ 
ing  software  on  personal  computers,  they  were  themselves  unable  to  change.  At 
the  time,  a  Wang  official  confidently  declared, 

“We  re  a  billion-dollar  company  and  billion-dollar  companies  don’t 
disappear  overnight.  ” 

But  when  IBM  faced  and  responded  to  the  new  realities  by  creating  the  word¬ 
processing  capable  personal  computer,  Wang  was  unable  to  change,  and  they 
were  soon  bankrupt. 


Figure  8-1  :A  Multiply  Stolen  Market 

At  one  time,  vacuum  tube  giants  GE,  RCA,  Raytheon,  and  Sylvania  absolutely 
controlled  the  electronics  industry.  But  they  do  not  today;  others  seized  many  of 
the  new  opportunities.  Are  the  current  leaders  equally  temporary?  There  are  so 
many  examples  of  companies  not  being  able  to  change-to  keep  up~that  one  has 
only  to  go  back  a  few  decades  to  see  a  50%  turnover  in  the  Fortune  100. 

What  did  the  losers  do  wrong?  These  firms,  most  of  them,  were  paragons  of 
good  management;  they  delighted  their  customers  with  excellent  sales  personnel; 
they  had,  relatively  speaking,  flat,  knowledge-driven  organizations  and  empow¬ 
ered,  educated  workforces.  But  they  could  not  anticipate  change.  Who  could? 
Their  actual  problem  was  that  they  couldn’t  respond  to  the  unanticipated  change 
even  when  knew  that  the  earth  was  moving  under  their  feet.  What  they  lacked  was 
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agility,  which  we  define  simply  as  the  ability  to  respond  to  unexpected  change.  The 
research  on  which  we  report  provides  help  toward  a  better  understanding  of  agil¬ 
ity  as  well  as  specific  steps  on  how  to  engineer  the  correct  amount  and  type  of  agil¬ 
ity  into  an  enterprise. 

One  thing  is  clear:  agility  is  largely  independent  of  other  best  management  ap- 
proaches  that  a  business  can  practice.  Your  ability  to  make  things  better,  faster,  and 
cheaper  today  says  nothing  (or  very  little)  about  your  ability  to  change  (in  a  fast  and 
cheap  way)  to  make  something  else  better,  faster,  and  cheaper  (or  to  respond  in 
other  respects  to  unanticipated  changes). 


Profit  Tomorrow 


Old  Focus - ^  New  Focus 

(static,  optimized  enterprise)  (living,  dynamic  enterprise) 

Figure  8-2 :On  Beyond  Better,  Faster  and  Cheaper 


If  you  have  a  flat  organization,  according  to  best-in-class  standards,  will  you  be 
more  agile?  Maybe  not.  In  fact,  what  put  Wang  out  of  business  was  IBM  roaring 
back  by  entering  (some  would  say  creating)  the  PC  business.  IBM  was  able  to  re¬ 
spond  successfully  because  of  the  previously  underutilized  skills  of  their  thick, 
many-layered  technical  management  pool.  They  continued  to  be  remarkably  suc¬ 
cessful  in  responding  to  change  in  the  PC  business  as  long  as  they  could  handle  it 
in  the  same  fashion  as  their  typewriter  business  (as  personal  letter-writers  and 
adding  machines).  When  PCs  started  looking  more  like  ofbet  computes,  and  com¬ 
peted  with  their  other  business  (mainframe  computers  which,  inside  IBM,  used  an¬ 
other  paradigm),  they  had  troubles.  But  that  s  another  story. 

If  you  have  a  lean  organization,  as  conventionally  understood,  will  you  automat¬ 
ically  have  agility?  Consider  the  following  example.  Toyota,  and  other  Japanese 
auto  manufactur0rs,  gained  a  foothold  in  the  U.  S.  originally  because  . 

pened  to  be  making  small,  efficient  cars  at  a  time  when  the  oil  price  shocks  made 
those  cars  attractive  to  U.  S.  buyers.  Originally,  the  attraction  to  the  consumer  was 
^simply  the  size  of  the  car  and  a  low  price  resulting  from  an  artificially  strong  dollar. 
Quality  wasn't  part  of  the  equation  at  first.  U.  S.  automakers  were  stuck,  having 
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invested  in  plants  and  processes  for  larger,  gas-guzzling  cars  that  it  was  hard  to 
adapt  to  the  new  kind  of  product. 

Later,  both  quality  and  lean  production  techniques  quickly  became  competitive 
issues.  Ford  and  GM  rushed  to  become  lean.  The  first  targets  were  reductions  in 
their  supplier  base,  with  the  remaining  pool  being  more  qualified.  Most  initial  suc¬ 
cess  was  in  drivetrain  suppliers.  Both  GM  and  Ford  went  irom  a  very  large  pool  of 
suppliers  to  a  highly  integrated,  much,  much  smaller  set.  Savings  were  immediate. 

Meanwhile,  Chrysler  was  not  becoming  lean  as  fast  as  Ford  and  GM,  and  it  was 
not  doing  well  in  the  market  either.  Consumers  just  weren’t  buying  many  of  their 
cars.  Chrysler  decided  that  a  good  selling  point  would  be  to  offer  driver’s  seat  air¬ 
bags,  and  they  did  so.  Ads,  featuring  their  CEO,  touted  this  advantage. 

An  exploited  opportunity  here: 

Ford  Steering  Wheel  Suppliers  Chrysler  less  lean,  but  more  agile 


Ford  Agility 

Chrysler  Agility 

_ 

Chrysler  Leanness  ^ 

Ford  Leanness 

In  introducing  airbags,  Chrysler  exploited  the  fact  that  Ford’s  rush  to  reducing  sup¬ 
pliers  rendered  the  supply  chain  less  adaptable. 

Figure  8-3:Agility  as  a  Competitive  Weapon  Against  Lean 

We’ve  heard  two  versions  of  this  story,  one  of  which  makes  Chrysler  appear  wis¬ 
er  than  the  other.  What  happened  was  that  Chrysler  was  far  behind  on  becoming 
lean,  insofar  as  reducing  suppliers.  So  they  had  a  large  pool  of  steering  wheel  sup¬ 
pliers.  Since  installing  airbags  in  steering  wheels  stretched  existing  processes  con¬ 
siderably,  it  was  helpful  to  have  this  large,  competitive  pool.  Ford  and  GM  took 
years  to  adjust,  hampered  by  their  lean  supply  chains,  which  were  efficiently  tar¬ 
geted  on  old-style  steering  wheels.  Meanwhile,  Chrysler  attracted  a  substantial 
number  of  crossover  buyers.  One  version  of  the  story  has  Chrysler  targeting  this 
weakness  accidentally.  Another,  less  likely,  version  credits  Chrysler  with  intention¬ 
ally  hitting  their  competition  where  they  were  weak,  meaning  un-agily-lean. 

We  assert  that  agility  is  something  separate  and  apart  from  being  better,  faster, 
land  cheaper,  merely  being  profitable  today.  Rather,  it  is  the  ability  to  be  profitable 
tomorrow,  presumably  by  being  better,  faster,  and  cheaper  in  different  ways.  Agil¬ 
ity  is  a  concept  that  investment  firms  implicitly  understand  and  use.  Everyone  can 


Fctniary  IS,  1^97 


129 


Part  2.  Agility  Issues 


see  how  profitable  you  are  today;  that’s  not  the  most  important  question.  An  in¬ 
vestor  is  more  concerned  with  how  likely  you  are  to  be  profitable  tomorrow. 

In  a  sense,  some  agility  is  free.  You  can  get  a  limited  amount  of  agility  by  em¬ 
ploying  good  management  practices  that  you  have  may  adopt  independently  of 
agility  concerns.  For  instance,  good  customer  monitoring  has  to  be  helpful  all- 
around.  If  you  invest  in  better,  more  robust  insight  into  customer  needs  in  order 
to  be  profitable,  that’s  also  likely  to  help  you  be  agile. 

But  most  agility  will  cost  money.  You’ll  invest  in  agility  as  a  hedge,  much  as  you 
already  do  with  insurance  coverage.  Some  would  say  the  least  useful  kind  of  agility 
would  be  an  excessive  capability  for  change  and  especially  for  change  that  is  in  the 
wrong  areas-in  other  words,  agility  that  you  never  use,  that  you  spent  your  stock¬ 
holder’s  money  on  and  didn’t  need.  But  even  more  crucial  in  many  cases  is  the  agil¬ 
ity  that  you  do  need  but  just  don’t  have,  which  hurts  your  position.  Just  like 
insurance. 

This  report  describes  work  on  metrics  for  agility.  The  metrics  are  intended  to 
provide  a  first  step  toward  a  management  science  of  agility,  and  to  be  immediately 
useful  to  managers  wishing  to  make  informed  decisions  about  agility.  One  appli¬ 
cation  is  in  a  three-step  agility  assessment: 

Step  1  in  the  assessment  would  evaluate  the  threat;  identifying  the  areas  in 
which,  and  the  extent  to  which,  agility  would  be  required.  This  step  gives  your  best 
guess  on  how  unstable  the  sand  is  under  your  feet  and  in  which  direction  it  is  more 
likely  to  slide.  Our  new  metrics  will  not  help  with  this  particular  evaluation,  other 
than  to  generally  illuminate  the  dimensions  of  the  problem.  We  consider  that  con¬ 
ventional  actuarial  analyses  can  cover  this  problem,  fitting  right  in  with  other  stra¬ 
tegic  evaluations  of  change  within  the  environment.  But  we  do  suggest  a 
promising  structured  controversy  brainstorming  technique. 

Step  2  in  the  assessment  would  be  to  evaluate  your  ability  to  address  the  threat. 
Here,  we  will  be  able  to  help  you  predict  the  time  and  cost  of  change,  given  specific 
configurations  within  your  enterprise. 

Step  3  would  direct  you  to  specific  tools  and  techniques,  ideally  through  case 
studies,  to  address  your  specific  weaknesses.  Several  groups  are  working  this 
problem,  the  most  notable  the  Agility  Forum  at  Lehigh  University,  and  the  three 
Agile  Manufacturing  Research  Centers.  As  with  step  one,  our  metrics  only  general¬ 
ly  inform  this  step,  except  through  the  rules  of  thumb  noted  below. 


Figure  8-4;Three  Steps 
f 

The  targeted  initial  use  of  the  metrics  is  as  a  tactical  tool;  you  already  have  a 
corporate  or  enterprise  strategy,  which  has  as  a  component  where  and  how  much 
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you  want  agility.  You  are  faced  with  a  given  number  of  alternatives,  for  example, 
competing  members  within  your  supply  chain.  Naturally,  you  have  ways  of  evalu¬ 
ating  the  time,  cost,  and  quality  of  these  suppliers  in  the  static  situation.  We’ll  help 
you  determine  the  time  and  cost  of  change  in  the  manner  and  extent  that  your 
strate^  requires.  So,  the  actual,  real  overall  cost  of  doing  business  with  them  as 
conditions  change  can  be  evaluated  (by  combining  the  results  of  our  metrics  with 
your  measures  of  better-faster-cheaper). 

We’ll  give  some  indications  about  the  use  of  the  metrics  for  the  more  technically 
challenging  situation  of  strategic  planning.  Here,  you  would  need  to  incorporate 
the  metrics  with  your  own  (or  your  consultant’s)  strategic  analysis  tools;  you  would 
need  the  ability  to  perform  quick  evaluations  as  well  as  high  confidence  simula¬ 
tions;  and  you’d  need  the  ability  to  evaluate  many  options  with  many  alternatives, 
taking  into  account  numerous  factors  in  your  organization  and  those  of  your  part¬ 
ners,  competitors,  and  customers. 

Perhaps  the  best  use  of  this  type  of  strategic  agility  is  as  an  active  competitive 
weapon,  not  merely  a  response,  as  in  one  interpretation  of  the  Chrysler  experi¬ 
ence.  An  example  of  agility  as  a  weapon  is  available  in  the  famous  Burger  King  as¬ 
sault,  described  below. 

Finally,  we  expect  that  one  result  of  adopting  this  approach  to  metrics  will  be 
the  appearance  of  certain  rules-of-thumb  for  particular  situations  in  agility  which 
can  be  applied  even  without  the  specific  analysis  by  metrics. 

In  addition  to  the  targeted  use  of  metrics  by  strategic  managers  and  middle-lev¬ 
el  decisionmakers,  we  also  expect  these  metrics  will  be  used  by  the  investment 
community  to  evaluate  companies’  future  prospects. 

8.1  Burger  Wars 

|An  example  where  agility  is  used  as  a  competitive  weapon.) 

For  the  Best  Agile  Practice  study  we  interviewed  a  number  of  companies,  some 
of  whose  cases  were  not  used  in  that  report.  This  case  was  too  old  and  too  com¬ 
plicated  to  fit  the  Forum’s  template,  but  is  quite  interesting  nonetheless.  These  in¬ 
sights  come  from  a  senior  VP/strategist  at  a  fast  food  parent  company  who  spoke 
from  experience. 

Most  of  us  will  remember  the  early  days  of  the  burger  wars.  MacDonald’s  was 
the  Toyota  of  the  restaurant  business;  it  emphasized  lean  (no  pun  here)  processes 
based  on  burgers,  shakes,  and  fries,  and  they  took  the  nation  by  storm,  offering 
the  advantages  of  low  cost  and  convenience. 

My  Informant  described  wonderful  examples,  well  known  in  the  literature,  he 
said,  of  detailed  studies  of  such  concerns  as  the  optimum  combined  grill/spatula 
size,  and  a  shake  process  which  knocked  1/2  second  off  preparation  time,  and  so 
on.  The  entire  kitchen  was  based  on  the  most  efficient  processes  geared  to  an  ex¬ 
tremely  limited  menu.  A  tremendous  investment  went  into  understanding  those 
processes  and  designing  the  best  equipment  and  processes. 
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MacDonald’s  ended  up  with  a  huge  physical  investment  in  equipment  which  was 
optimized  for  a  small,  standardized  menu  set.  Enter  Burger  King.  They  put  them¬ 
selves  on  the  map  by  pursuing  a  brilliant  strategy:  they  figured  that  people  would 
tire  of  burgers  alone,  if  they  were  reminded  of  the  monotony.  So  they  began  via 
advertising  by  sowing  dissatisfaction  with  the  standardized  condiments  on  pre¬ 
made  burgers. 

Burger  King  designed  a  set  of  assembly  line  equipment  and  processes  which  did 
cost  more,  but  were  also  more  agile  In  a  way  that  their  competition  couldn't  match. 
You  might  remember  the  system,  a  two-tiered  moving  grill  conveyor,  the  top  for 
toasting  the  buns,  the  bottom  for  the  meat.  Burgers  were  made  one  at  a  time,  the 
process  beginning  with  the  customer’s  order. 

The  tactic  was  to  emphasize  that  the  customer  could  have  It  their  way,  with  a 
tailored  set  of  dressings.  And  they  advertised  the  dickens  out  of  it,  educating  the 
customer  to  expect  more,  and  this  severely  hurt  MacDonald’s.  During  this  period 
Burger  King’s  growth  far  exceeded  MacDonald’s.  This  provides  an  example  of  agil¬ 
ity  employed  as  a  tactic  specifically  targeted  to  the  weaknesses  of  a  lean  competi¬ 
tor.  But  the  initial  agility  was  focused  on  the  physical  infrastructure,  exactly  as  in 
flexible  manufacturing. 

The  longer  term  strategy  was  even  more  interesting.  Burger  King  figured  that 
they  could  use  the  equipment  and  kitchen  layout  for  a  larger,  more  dynamic  menu. 
It  was  specifically  designed  for  agility  in  this  way.  Burger  King  impinged  on  Mac¬ 
Donald’s  business  by  offering  a  steady  stream  of  specialized  sandwiches,  empha¬ 
sizing  their  variety  (including  different  shapes,  a  feature  very  hard  for  MacDonald’s 
to  imitate).  They  knew  that  by  changing  consumer  expectations  in  this  way  they 
would  force  MacDonald’s  to  completely  reinvent  their  processes  and  to  replace  all 
of  their  equipment. 

And  it  worked.  MacDonald’s  had  to  toss  out  all  of  their  special  equipment  and 
replace  it  with  a  more  flexible  physical  plant.  The  resulting  cash  demands  on  Mac¬ 
Donald’s  allowed  Burger  King  to  grow  unchecked  to  be  a  nearly-equal  competitor, 
since  they  could  use  their  money  for  marketing  and  growth.  Incidentally,  Mac¬ 
Donald’s  learned  a  lot  about  using  the  physical  plant  as  a  competitive  weapon.  In 
the  process  of  remodeling,  they  invested  in  playgrounds  in  the  restaurant,  creating 
a  niche  and  providing  an  attraction  that  Burger  King  could  not  boast. 

So  far,  we  have  an  example  with  agile  adjustments  in  physical  and  legal/explicit 
(in  this  case,  the  process  plans)  infrastructures.  As  it  turns  out,  the  processes  and 
equipment  used  today  have  been  revolutionized  by  changes  In  the  information  in¬ 
frastructure.  Burger  King,  MacDonald’s,  and  others  are  now  pretty  much  the  same 
insofar  as  processes  and  equipment  are  concerned.  Meanwhile,  Rally’s  and  others 
have  made  a  thriving  business  by  entering  the  niche  that  MacDonald’s  left:  a  very 
limited  menu  produced  by  an  optimized,  cheap  kitchen. 

The  dynamics  are  exactly  as  found  in  the  Chrysler  steering  wheel  example. 

^  The  burger  war  historian  told  us  that  today,  significant  competitive  differences 
among  the  big  players  focus  instead  on  a  variety  of  human,  social  and  intangible 
elements.  Some  of  these  shed  light  on  our  soft  agility  studies  and  will  be  explored 
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later.  For  now,  we  can  at  least  notice  these  four  categories  of  infrastructure-phys¬ 
ical,  legal,  social,  and  informational-all  of  which  provide  opportunities  for  agility. 
We  characterize  these  categories  and  address  the  opportunities  in  Part  1. 

8.2  Competitive  Games 

|An  example  sector  where  market  share  is  highly  dynamic.) 

Examples  are  distributed  through  the  report.  But  of  ail  sectors,  consumer  elec¬ 
tronics  is  the  most  dynamic;  and  within  that  sector,  the  game  console  industry  is 
pretty  interesting. 

The  story  begins  with  Nintendo  introducing  their  NES  to  great  success  to  cap¬ 
ture  a  market  orphaned  after  the  Mattel/Atari  collapse.  Their  approach  was  much 
like  Microsoft's  in  the  personal  computer  business:  capitalize  on  the  large  user 
base  to  quickly  build  a  massive  cadre  of  good  and  not-so-good  developers  to  del¬ 
uge  the  market,  creating  a  proprietary  product  stream  which  completely  dominat¬ 
ed  the  market. 

Along  comes  Sega,  with  a  superior  platform,  the  1 6-bit  Genesis.  It  only  had  a  few 
games,  but  each  was  the  best  in  class.  In  a  new  business  model,  Sega  worked  only 
with  a  select  group  of  developers.  Newer  games  were  few,  but  excellent.  It  was  a 
formula  that  worked.  Nintendo,  completely  stymied,  was  sunk.  The  release  of  their 
Super  NES  was  much  too  late.  Nintendo  had  lost,  because  Sega  changed  the  rules. 

Nintendo  held  on  to  niches  (Japanese,  Gameboy),  while  Sega  moved  to  consoli¬ 
date  power  with  its  Saturn.  But  the  rules  were  to  change  again.  Sony  is  a  master 
of  advertising,  and  they  recognized  a  malleable  market.  In  a  blizzard  of  advertis¬ 
ing,  they  swept  in  with  their  PlayStation  and  completely  beat  the  pants  off  of  ev¬ 
eryone.  The  older  players  had  wearied  themselves  in  a  feature  war,  and  Sony  had 
trumped  them  with  promoting  image. 

But  wait!  Recently  Nintendo  moved  to  redefine  the  industry  back  to  excellence 
of  product.  They  introduced  their  Nintendo64  (with  Mario64)  and  sold  out  in 
stores  everywhere  in  hours.  The  consultants  who  worked  on  this  project  revealed 
the  hidden  strategy.  In  an  industry  where  huge  leadership  swings  took  place  (Mat¬ 
tel  to  Nintendo  to  Sega  to  Sony  and  back  to  Nintendo)  the  winners  are  the  ones 
who  can  completely  redefine  themselves  both  in  response  to  threats  and  to  stra¬ 
tegically  redefine  the  rules  to  be  most  uncomfortable  for  the  competition. 

The  trick  was  to  become  agile,  to  use  agility  as  a  weapon.  You  know  who  they 
took  as  their  example?  McDonnell  Douglas,  the  group  that  designed  the  space  sta¬ 
tion  and  redesigned  and  redesigned  and  redesigned  it  in  response  to  a  fickle  cus¬ 
tomer  (the  micromanaging  Congress)  until  learning  how  to  change  the  rules  so  as 
to  manipulate  the  situation. 
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9  Government  Sponsorship 

[This  section  outlines  the  sponsors  of  the  project  and  provides  a  rationale  for  them  to  lead  agility  research.] 

9.1  What  is  the  Domestic  Advantage? 

(Results  of  studies  on  agility  benefits  to  the  economy.] 

Government  support  of  agility  can  benefit  the  U.  S.  Economy. 

Since  a  primary  goal  of  AVEs  is  increased  profitability  and  productivity  in  busi¬ 
ness  enterprises,  the  U.  S.  economy  will  benefit  in  the  aggregate.  How  much  pro¬ 
ductivity  will  result  is  impossible  to  predict;  some  widely  circulated  numbers  are 
not  supportable.  With  key  infrastructure  suppliers,  we  conducted  some  in-depth 
studies  to  shed  light  on  the  benefits  of  the  VE,  producing  new  knowledge  in  key 
areas,  some  of  which  is  reported  below. 

9.1.1  U.  S.  Enterprises  Benefit  Relative  to  International  Competitors 

(Agility  leverages  U.  S.  strengths  in  innovative  small  businesses  and  case  law.) 

We  studied  the  costs  of  integrating  and  managing  processes  in  the  U.  S.  com¬ 
pared  to  the  international  competition.  The  results  were  startling.  The  study  fo¬ 
cused  on  high-value  manufactured  components,  because  this  is  where  the  major 
competition  exists.  (A  high  proportion  of  foreign  low-value  manufacturing  and  as¬ 
sembly  directly  benefits  U.  S.  business  anyway.) 

In  every  case  examined  (automobiles,  commercial  aircraft,  consumer  electron¬ 
ics,  small  appliances,  semiconductors)  the  major  determining  factor  in  the  compe¬ 
tition’s  relative  success  was  not  low  labor  cost,  access  to  cheap  capital,  or  the 
benefit  of  government-sponsored  research.  Rather,  it  was  the  low  cost  (relative  to 
the  U.  S.)  of  integrating  their  enterprises.  (A  parallel  study  was  performed,  with 
similar  results  on  the  Soviet,  now  multinational,  military  aircraft  enterprise.) 

The  reasons  for  this  are  related  to  how  we  and  our  competitors  traditionally  do 
business.  When  Sony  designs  a  product,  they  do  so  knowing  who  is  going  to  build 
its  components,  so  they  can  predict  or  dictate  what  processes  are  going  to  be 
used.  The  typical  Japanese  enterprise  is  a  very  stable,  vertically  integrated  enter¬ 
prise.  The  typical  European  enterprise  is  similarly,  though  less,  integrated  and  sta¬ 
ble,  but  without  the  shared  ownership  which  characterizes  the  Japanese. 

A  typical  U.  S.  enterprise  is  dynamic;  the  rules  of  composition  are  dominated  by 
the  forces  of  competition.  The  major  benefit  of  this  system  comes  from  the  inno¬ 
vativeness  of  small,  agile  businesses.  In  this  area,  the  U.  S.  is  unparalleled.  Howev¬ 
er,  the  cost  of  quickly  integrating  processes  of  a  small  business  (or  component  of 
a  large  corporation)  into  the  supplier  chain  is  excessively  expensive  in  terms  of  ef¬ 
fort,  time,  and  cost.  This  amounts  to  a  critical  disadvantage  for  U.  S.  enterprises. 

In  a  growing  number  of  U.  S.  industries,  a  quantity  of  small  business  innovators 
■>are  being  driven  out  of  the  supply  chain  by  the  increasingly  high  cost  of  doing  busi- 
'  ness.  Pressure  comes  both  from  within  the  small  businesses,  who  would  rather  put 
resources  on  their  core  competencies,  and  from  large  primes  who  prefer  to  reduce 
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the  number  firms  under  them,  to  reduce  the  cost  of  integration  overhead.  An  oth¬ 
erwise  classified  study  has  reported  a  disastrous  decline  in  the  number  of  small, 
and  presumably  innovative,  businesses  involved  in  the  current  generation  of  aero¬ 
space  weapon  systems. 

This  phenomenon  was  directly  linked  to  higher  costs. 

The  studies  indicated  that  if  the  cost  of  assembling  an  integrated  U.  S.  enter¬ 
prise  were  lowered,  then  the  relatively  stronger  engines  of  innovation  and  compe¬ 
tition  would  put  every  high-value  U.  S.  manufacturing  enterprise  at  a  structural 
advantage.  The  international  competition  would  lack  the  agility  to  keep  up,  as 
their  staid,  long-lived  structures  would  be  slow  to  evolve.  Their  reliance  on  vertical 
integration  and  stability  is  intrinsically  unagile. 

Additionally,  it  was  found  that  improved  capabilities  in  non-manufacturing  in¬ 
formation  infrastructure  in  many  cases  resulted  from  improvements  originally 
funded  by  the  rnanufacturing  sector.  When  VE  suppliers  were  polled  under  nondis¬ 
closure  protection,  it  was  found  that  62%  of  all  improvements  underway  were  driv¬ 
en  by  market  forces  originating  with  manufacturing  customers.  (All  numbers  in  this 
section  are  from  1993.)  Thus,  other  business  enterprises  (financial  and  retail  ser¬ 
vices,  or  petrochemical/pharmaceutical  industries)  and  nonbusiness  enterprises 
(government  and  nonprofit  activities)  will  benefit  directly  from  attention  to  the  in¬ 
dustrial  VE. 

A  surprising  competitive  advantage  was  discovered;  the  use  of  common  (or  case) 
law  in  the  U.  S.  Most  of  our  international  competitors  (the  European  Community, 
Japan,  other  Pacific  Rim  countries,  and  in  the  future,  China)  use  law  based  on  code. 
The  movieAvhaling  example  shows  one  direct  advantage  from  the  U.  S.  system.  It 
would  be  desirable  if  the  infrastructure,  and  specifically  the  metrics,  were  engi¬ 
neered  to  leverage  this  advantage.  So  we  can  consider  this  both  as  a  present  struc¬ 
tural  advantage  and  as  a  potentially  greater  advantage. 

9.1.2  U.  S.  Benefits  as  Suppliers  ofVE  Infrastructure  Products 

[The  U.  S.  is  likely  to  provide  the  majority  of  the  agile-sensitive  information  infrastructure  of  the  world.) 

The  idea  of  suppliers  of  VE  infrastructure  is  a  new  one,  so  we  had  to  conduct 
some  market  surveys  to  understand  the  dynamics  and  characteristics  of  the  VE 
marketplace.  The  studies  used  the  ICEIMT  IGORA92al  definition.  VE  infrastructure 
technology  suppliers  were  found  to  be  different  from  VE  service/application  sup¬ 
pliers.  The  latter  are  characterized  by  large  users  (Boeing,  GE,  GM,  the  manufactur¬ 
ing  side  of  IBM  for  examples),  who  supply  services  to  themselves,  and  system 
integrators  who  supply  services  to  others.  The  service  suppliers  can  add  value  only 
within  the  range  of  the  capability  envelope  provided  by  the  technology  suppliers. 
Therefore,  the  chief  pressure-points  for  VE  capabilities  are  the  technology  suppli¬ 
ers. 

)  This  group  of  companies  is  surprisingly  small  in  number,  consisting  of  IBM,  Dig¬ 
ital,  and  a  loose  federation  of  companies  (including  those  mentioned)  which  add 
value  to  UNIX  (Hewlett-Packard,  Sun  and  then  NCR).  (Microsoft,  Apple,  and  Unisys 
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were  not  critical  players  in  the  manufacturing  enterprise  as  of  1992,  the  time  of 
the  study.  Since  then,  Netscape  and  NeXT  have  also  emerged  as  players.)  That 
these  companies  are  in  the  process  of  redefining  their  infrastructure  products  is 
good  news  for  the  VE  program.  Also  important  is  the  fact  that  all  of  the  major  sup¬ 
pliers  are  U.  S.-based  firms. 

In  fact,  if  the  larger  companies  are  decomposed  by  national  geography  and  VE- 
related  infrastructure  products  are  assigned  to  the  decomposed  elements,  some 
interesting  insights  are  gained.  If  one  counts  a  non-U.  S.  based  component  of,  say, 
IBM  as  a  foreign  company,  and  the  U.  S.  based  component  of  a  non-U.  S.  based  com¬ 
pany  also  as  a  foreign  company,  73%  of  all  VE  technology  still  comes  from  a  U.  S.- 
owned  component  based  in  the  U.  S. 

The  U.  S.,  therefore,  currently  has  most  ofthe  jobs,  the  technology,  and  the  mar¬ 
ket  of  a  potential  VE  infrastructure  economy.  As  the  VE  market  grows,  the  U.  S.  will 
experience  growth  in  this  market  sector,  as  a  first  order  economic  benefit.  It  is  no¬ 
table  that  these  VE  technologies  fit  the  traditional  definition  of  strategic  technol¬ 
ogies:  they  are  the  beginning  of  the  food  chain  for  most  of  the  world’s  industrial 
economy.  It  is  possible  that,  as  routine  integration  becomes  simpler,  the  systems 
integration  middleman  business  will  shrink.  As  a  result,  U.  S.-dominated  VE  tech¬ 
nology  suppliers  will  become  more  strategically  important  to  world  business. 

9.1.3  U.  S.  Benefits  as  Suppliers  ofVE  Infrastructure  Processes 

[The  U.  S.  is  likely  to  supply  a  high  percentage  of  innovative  process  technology  into  a  world  of  agile  enterpris¬ 
es.! 


By  most  measures,  the  U.  S.  is  the  most  active  developer  of  process-related  in¬ 
tellectual  property  in  the  world.  In  another  study,  we  sought  to  understand  the  po¬ 
tential  for  a  new  trade  based  on  the  licensing  of  process-based  intellectual 
property  from  one  firm  to  another.  It  is  considered  unlikely  that  an  enterprise 
would  wish  to  transfer  processes  which  it  uses  to  competitive  advantage  to  a  com¬ 
petitor.  So  attention  was  given  to  processes  which  could  be  traded  across  business 
sectors. 

This  was  a  difficult  analysis;  while  businesses  know  how  much  they  spend  on 
hardware,  and  try  to  know  how  much  they  spend  on  software,  there  is  presently 
less  incentive  for  knowing  how  much  is  invested  in  process  development.  Propri¬ 
etary  information  supplemented  new  floor  surveys  (under  our  initiative)  in  statis¬ 
tically  representative  manufacturing  companies.  The  category  of  process-related 
investment  was  called  Enterprise  Characterization  [GORA92bl.  In  general,  this  cat¬ 
egory  consisted  of  all  explicitly  captured  process  information  which  is  recognized 
in  some  way  by  the  information  infrastructure. 

A  staggering  $160B  per  year  worldwide  is  spend  on  enterprise  characterization. 
Within  specific  sectors  such  as  semiconductor  manufacturing  90%  (plus  or  minus 
^5%)  of  a  huge  amount  of  money  was  spent  on  characterizations  which  are  common 
(i.e.,  shared  and  potentially-transportable).  70%  of  the  money  was  spent  on  charac¬ 
terizations  found  to  be  common  across  the  electronics  and  the  automotive  manu¬ 
facturing  sectors.  Transportability  of  processes  in  the  case  of  service  sectors  was 
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not  easily  determined.  Of  these  expenses,  70  to  90%  was  deemed  actually  feasible 
for  commerce  (i.e.,  for  selling  processes),  depending  on  the  industry.  The  enter¬ 
prise  characterization  components  had  a  surprisingly  long  life,  a  half-life  of  7.5 
years.  This  indicated  that  a  several  hundred  billion  dollar  economy  in  process  tech¬ 
nology  is  theoretically  possible,  though  of  course  probably  in  practice  somewhat 
further  limited  by  other  legal  and  market  forces. 

U.  S.  firms  would  benefit  by  being  able  to  avoid  reinventing  processes  by  acquir¬ 
ing  those  not  in  their  core  competency,  including  processes  developed  overseas. 
Some  U.  S.  firms  would  benefit  from  selling  processes  to  non-U.  S.  companies  in 
other  sectors,  allowing  increased  investment  in  new  processes. 

(A  much  more  detailed  Suppliers’  Working  Group  report  on  these  issues  is  avail¬ 
able  for  internal  government  use  from  the  Air  Force  Wright  Laboratories  Manufac¬ 
turing  Technology  Directorate.  This  combined  proprietary  information  from  many 
sources  to  obtain  results  and  is  not  available  to  the  public.) 

9.1.4  User  Firms  Can  Leverage  the  AVE 

(Agile  enterprises  are  more  likely  to  do  well  in  other  desirable  traits,  such  as  quality  and  productivity.] 

Often,  industrial  users  consider  the  primary  advantage  from  VE  to  be  in  its  em¬ 
powering  of  some  technical  strategy  which  they  deem  important  to  their  compet¬ 
itive  posture.  These  strategies  are  diverse,  and  none  of  them  apply  to  all  sectors. 
But  In  each  case,  the  VE  can  provide  an  underlying  infrastructure  which  empowers 
Agile/F\e\\b\e/Rapid-ResponseA.ean  Manufacturing,  Total  Quality  Management. 
Concurrent  Engineering,  Soft/Virtual  Prototyping)  or  Electronic  Commerce.  Occa¬ 
sionally,  the  user  will  eschew  these  concepts  to  focus  on  a  single  metric,  such  as 
improved  quality,  reduced  costs,  reduced  cycle  time,  enhanced  markets  or  flatten¬ 
ing  of  the  organization. 

For  many  of  these  cases,  limited  tools  already  exist.  But  the  market  for  any  one 
of  these  applications  is  too  small  to  effect  a  major  change  in  the  basic  infrastruc¬ 
ture.  Yet  if  one  envisions  the  components  of  the  AVE  as  including  elements  within 
an  enterprise,  then  the  technical  requirements  of  the  AVE  cover  many  of  the  harder 
issues  of  these  applications  of  enterprise  Integration.  The  VE  provides  an  overarch¬ 
ing  concept  which  unifies  some  technical  issues  among  the  components  and  opens 
the  market  sufficiently  to  warrant  addressing  the  tough  problems. 

Champions  of  all  the  above-mentioned  approaches  have  presented  business  cas¬ 
es.  Some  of  these  are  more  developed  than  others.  But  it  is  clear  that  if  the  AVE 
contributes  to  the  success  of  any  of  them,  major  benefits  to  industry  will  accrue. 

9.1.5  New  Entrants  into  the  Market  will  be  Possible 

|lt  will  be  easier  for  innovative  startups  to  thrive,  another  U.  S.  strength.] 

^  Currently,  the  major  VE  technology  suppliers  are  all  hardware  suppliers.  This  Is 
a  legacy  of  how  the  market  developed:  first  as  operating  environments,  then  as  lay¬ 
ered  middle-ware  components  in  (a)  larger  system  architecture(s).  Often  the  oper- 
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ating  environment  is  the  competitive  discriminator  among  suppliers,  and  the 
barriers  to  entry  are  substantial. 

As  proposed,  the  AVE  will  open  the  market  so  Innovative  firms  could  enter  all  or 
part  of  the  market.  This  could  help  revitalize  the  software  industry  by  Itself,  and 
most  of  the  likely  entrants  are  U.  S.  firms. 

9.2  What  is  the  Defense  Advantage? 

[Results  of  studies  concerning  benefit  to  U.  S.  defense.  Defense  industries  cannot  be  agile  unless  commercial 
tools  exist.  If  so,  civil  suppliers  can  be  shifted  in  and  out  in  both  peace  giving  lower  costs  and  mobilized  for  emer¬ 
gencies,  providing  a  lower  cost  for  readiness.) 

The  case  here  is  straightforward  and  follows  the  long-lived  ManTech  tradition. 
The  Defense  Industrial  Base  is  less  than  5%  of  the  manufacturing  domestic  product. 
It  is  simply  too  small  to  support  any  particular  type  ofVE  infrastructure,  especially 
one  that  promotes  a  radical  idea  like  agility.  The  only  way  to  get  improved  VE  In¬ 
frastructure  into  the  defense  base  is  to  see  it  widely  accepted  and  supported  in  the 
domestic  commercial  base. 

Elsewhere,  we  will  make  the  case  that  there  are  few  barriers  to  cross  in  tailoring 
the  AVE  tools,  specifically  the  metrics,  in  cutting  across  defense  and  commercial 
users.  Fortunately,  the  defense  users  of  interest,  teams  which  design  and  manufac¬ 
ture  complex  weapons  systems,  represent  essentially  the  same  type  of  constituen¬ 
cy  for  agility  in  the  commercial  base.  In  the  latter  case,  the  users  will  be  teams 
making  high-value  added  consumer  products. 

A  second  order  benefit  concerns  the  two  meanings  of  dual-use.  The  convention¬ 
al  use  of  the  term  applies  to  a  team’s  ability  to  adapt  existing  processes  from  com¬ 
mercial  use  to  military  in  times  of  crisis.  But  there  is  a  much  more  promising  vision 
which  agility  empowers.  Ifthere  is  a  high  degree  of  agility  in  practice,  then  defense 
AVEs  should  be  able  to  readily  form  in  non-crisis  situations,  drawing  from  the  civil 
supplier/subcontractor  base. 

This  larger  pool  would  provide  for  more  competition:  lower  prices  and  greater 
innovation. 

In  fact,  the  need  for  this  latter  vision  is  already  upon  us.  The  U.  S.  defense  strat¬ 
egy  depends  on  an  ever-increasing  ability  to  field  more  and  more  sophisticated 
weapons  while  at  the  same  time  reducing  support  for  a  dedicated  infrastructure  to 
do  so.  Only  a  commercial  base  capable  of  AVEs  can  support  this  need. 
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10  The  Legacy  of  this  Approach 

IPrior  work  gave  the  project  a  running  start.  It  is  described  here.] 

This  project  was  small  and  brief.  It  was  supplemented  by  industry  participation 
which  leveraged  the  government  investment  manifold.  But  it  also  leveraged  pre¬ 
ceding  defense  manufacturing  programs  as  well  as  parallel  research  in  non-defense 
manufacturing  areas.  This  section  provides  just  a  brief  overview  so  that  the  reader 
can  place  the  presumptions  of  the  project  in  a  meaningful  context. 

10.1  Preceding  Work 

|How  a  specific  thread  lead  to  the  project.  Includes  a  S40M  private  study.] 

For  decades,  the  Intelligence  community  has  dealt  with  the  problem  of  many  in¬ 
dependent  sources  providing  intelligence  to  many  independent  analysts.  Yet  all 
these  parties  are  expected  to  virtually  aggregate  to  supply  coherent  perspectives 
on  big-picture  issues.  Many  of  the  sources  collect,  manage  and  provide  their  infor¬ 
mation  In  different  forms  (interviews,  photographs,  parametric  data),  using  differ¬ 
ent  assumptions.  Likewise,  the  analysts  use  different  tools  and  assumptions. 

The  situation  is  similar  to  the  design/manufacturing  AVE  in  many  ways.  Different 
skills,  world  views,  models,  organizations,  cultures  are  expected  to  automatically 
integrate  around  a  specific  customer  need,  a  query.  And  this  generally  happens 
well  after  basic  individual  collection/analyst  infrastructure  (the  equivalent  of  the 
supplier  base)  is  mature. 

In  recognition  that  a  specific  research  program  in  the  intelligence  community 
had  the  best  handle  on  this  model/agent  federation  problem,  there  was  an  attempt 
to  transfer  technology  to  the  Space  Station  program  early  in  its  life. 

There  was  a  recognition  that  the  Space  Station  was  a  highly  complex,  multipur¬ 
pose  device,  of  which  one  would  be  made  that  had  to  be  essentially  perfect  for  30 
years.  It  was  to  be  created  by  a  highly  decentralized  mob  with  diverse,  dynamic 
technical  and  cultural  goals.  One  billion  dollars  was  set  aside  for  the  Space  Station 
Information  System,  an  AVE-enabling  federating  infrastructure. 

After  substantial  technology  transfer  and  expenditure,  the  program  was  elimi¬ 
nated  (the  political  particulars  aren't  central  to  this  report),  and  the  researchers  mi¬ 
grated  to  defense  applications.  The  Advanced  Technology  Bomber  (B-2)  had  a  true 
disaster  story  resulting  from  its  attempt  to  avoid  federation  by  frail  central  infor¬ 
mation  management.  The  effort  moved  to  support  a  program  called  the  Automa¬ 
tion  of  Technical  Information,  later  known  as  CALS.  CALS,  phase  II  was  also  known 
as  the  DARPA  CAPS  (Computer  Aided  Procurement/Production  Support/System). 

Through  other  political  foibles,  CALS  became  a  standards  effort,  and  CAPS 
evolved  into  DICE,  the  DARPA  Initiative  in  Concurrent  Engineering,  and  also  into 
the  SEMATECH  effort.  Both  of  these  anchored  the  new  DARPA  Defense  Manufac¬ 
turing  Office. 

^  SEMATECH  is  a  two  billion  dollar  research  program,  jointly  funded  by  the  De¬ 
fense  Department  and  semiconductor  manufacturers.  The  rationale  was  to  pre¬ 
serve  a  domestic  supply  of  modern  integrated  circuits  for  defense  use  in  the  face 
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of  aggressive  and  possibly  offensive  Japanese  practices.  There  were  several  con¬ 
stituencies  behind  SEMATEOH,  and  these  competed  for  attention  and  resources. 

The  constituency  that  got  the  program  funded  (Congress,  Defense  and  the  ma¬ 
jor  firms)  looked  at  the  problem  as  not  one  of  manufacturing  chips,  but  manufac¬ 
turing  chip-making  factories  Making  these  factories  is  a  big  problem: 

^they  cost  between  $1  and  2  billion  apiece 

^they  involve  thousands  of  suppliers  of  equipment,  processes  and  material 
^the  product  (the  factory,  or  fab)  is  an  extremely  high-tech  item 
^many  components  from  suppliers  differ  in  key  ways  from  similar  components 
they've  supplied  to  other  fabs;  most  fabs,  even  within  the  same  company  are 
unique  in  key  ways;  the  rate  of  change  of  components  and  fab  architectures  is 
increasing 

^the  profitable  lifecycle  is  short,  only  a  few  years,  then  essentially  everything  is 
obsolete 

^the  key  to  success  is  to  get  all  this  integrated  quickly  so  that  the  yield  goes  up 
and  you  can  hit  a  slender,  product  technology-driven  opportunity  window 

This  is  the  AVE  problem.  A  special  subset  of  SEMATECH  spun  off  independently 
as  the  Suppliers'  Working  Group  (SWG).  This  was  a  special  project  facilitated  by 
DARPA/ManTech.  The  suppliers  were  potential  AVE  infrastructure  suppliers. 

Hundreds  of  millions  were  spent  researching  some  of  the  thornier  problems  in 
federation  in  the  AVE  context.  This  was  extremely  influential  work,  essentially 
none  ofwhich  is  in  the  public  domain,  save  the  SWG-sponsored  ICEIMT  (GORA92f]. 

This  work,  and  industry  attention,  was  brought  into  the  metrics  project,  allow¬ 
ing  for  the  substantial  leverage  over  the  project's  small,  direct  funding. 

10.2  Parallel  Trends  in  Theory 

ISeveral  scientific  trends  provided  low  cost  leverage  by  having  ready  answers  when  needed.) 

Several  parallel  trends  were  folded  into  the  effort.  These  also  had  the  effect  of 
expanding  the  impact  and  leveraging  the  funding  of  the  project. 

10.2.1  Linguistic/Syntactic/Situation  Theories 

(Recent  trends  in  Situation  Theory  were  helpful.) 

The  metrics  depend  on  understanding  dynamic  coupling  of  processes  through 
the  structure  of  how  they  communicate.  Real  vibrant  science  of  communication  is 
full  of  differing  perspectives,  esoterica,  and  emerging  results. 

The  dominant  thread  has  always  emphasized  semantics,  the  meaning  of  commu¬ 
nication.  But  there  have  always  been  alternative,  complementary  branches  of  lin¬ 
guistics,  language  and  mathematics  which  focus  on  the  structure,  syntax  and 
'context  of  communication. 
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Figure  10*1:Contributing  Programs 

In  particular  there  has  been  a  branch  of  information  science  which  is  interested 
in  the  complexity  of  computer  programs.  Questions  of  interest  are  the  intrinsic 
computing  cost  and  adaptability  of  computing  languages  and  algorithms. 

Another  pertinent  area  is  that  of  Speech  Acts.  This  line  of  thought  originated  in 
studies  of  cognition  and  communication,  and  is  a  central  part  of  much  thinking  in 
artificial  intelligence  and  knowledge  representation.  It  is  particularly  useful  to 
those  working  in  Multi  Agent  Systems. 

The  final  of  these  three  trends  is  Situation  Theory.  Originally  it  was  developed 
as  an  alternative  to  Chomsl^  grammars  which  places  primary  emphasis  on  the 
structure  of  an  utterance.  Situation  Theory  emphasizes  more  indirect  and  contex¬ 
tual  communication.  The  Stanford  Center  for  the  Study  of  Language  and  Informa¬ 
tion  was  the  focus  of  this  work. 

The  union  of  these  three,  through  our  BAST  (Business  Applications  of  Situation 
Theory)  workshops  accomplished  within  the  project,  provides  us  with  a  basis  for: 

^decomposing  processes  and  their  contexts  into  speech  acts 
^understanding  and  reasoning  about  the  processes  and  contexts 
^measuring  their  complexity  and  adaptability 

1 0.2.2  Category  Versus  Set  Theories 

(Work  in  the  structure  of  transforming  actions  provided  some  of  the  foundation.) 

>  Early  in  the  history  of  logic,  the  mathematical  foundation  of  logic  became  iden¬ 
tified  v^ith  the  mathematics  of  sets  via  Set  Theory.  Essentially  all  of  the  implement¬ 
ed  engineering  principles  in  programming  follow  this  tradition. 
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Yet,  mathematicians  have  developed  a  parallel  tradition  based  on  notions  of 
types  and  functions.  This  Category  Theory  can  also  be  used  as  the  basis  for  logic 
and  language,  equivalent  to  set  theory.  But  it  has  advantages  in  identifying  the 
transformative  process  at  work. 

Category  Theory,  while  relatively  unintuitive  compared  to  set  theory,  works 
well  with  the  linguistic  ideas  noted  above,  because  the  structure  of  the  process  is 
more  clearly  revealed.  As  a  formal  basis,  Categoiy  Theory  also  better  supports  the 
implementation  strategies  noted  below,  for  similar  reasons. 

10.2.3  Group/Graph  Theories 

jCroup  theories  provide  an  expected  boost  in  support  tools  for  analysis  in  a  second  generation.) 

Syntactic  approaches  with  categoric  underpinnings  have  been  used  in  a  research 
context  for  some  time.  A  problem  which  has  limited  the  approach  is  how  complex 
the  underlying  mechanics  become.  This  is  a  result  that  such  approaches  allow 
many  types  of  abstractions  to  be  easily  created  and  supported.  Without  some  sort 
of  constraining  methodology,  the  complexity  of  implementations  becomes  nasty 
and  unsupportable  for  real  world  use. 

We've  spent  a  lot  of  time  on  this  problem  on  the  prior  projects  noted  above,  and 
feel  that  constraining  the  abstraction  strategies  by  group-theoretic  means  is  the 
answer.  In  computerese,  this  translates  to  constraining  the  typing  strategies  so 
that  they  have  internal  structure  which  you  can  count  on  to  rigidly  simplify  con¬ 
straints. 

We  expect  to  develop  this  idea  in  a  tool  strategy.  The  mechanics  that  an  imple¬ 
mentor  can  use  have  actually  been  well  developed  on  the  theoretical  side  of  the 
physical  sciences. 

As  an  extra  bonus,  we've  found  that  group  theoretical  abstraction  (i.  e.  symme¬ 
tries)  helps  visualization  of  complex  situations  by  a  user/modeler  as  well  as  sup¬ 
porting  a  decomposition  within  tools  that  componentizes  thern.  Now,  we  begin  to 
get  closer  to  a  strategy  that  can  form  the  basis  of  mission  critical,  manageable  in¬ 
formation  infrastructure. 

10.2.4  Component  Integration 

[We  leveraged  emerging  trends  in  infrastructure  which  will  result  in  a  new  generation  of  tools  regardless  of  agil¬ 
ity.) 

Modern  tool  strategies  require  that  the  tools  be  implemented  as  manageable 
components.  As  a  practical  matter,  this  means  we  need  to  componentize  the  ab¬ 
straction  strategy.  But  such  a  thing  is  only  possible  if  the  environment  can  support 
such  a  dynamic  coupling  between  components  which  do  the  work,  and  compo¬ 
nents  which  represent  fundamental  properties  about  how  you  do  the  work. 

In  particular,  you  need: 

'  4 A  reflective  language,  a  language  that  is  self-aware  of  its  own  functional  syntax 

and  can  modify  the  same.  LISP,  the  original  language  of  artificial  intelligence  was 
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A  well  formed  process  where: 


Complexity 

Agility 


=  Constant 


Figure  10-2:Several  Contributing  Components 


designed  with  this  in  mind,  and  more  modem  implementations  of  this  idea  are 
Smalltalk  and  Dylan. 

^Dynamic  objects  at  the  system  level.  This  is  a  tricky  one.  The  enterprise  is 
defined  by  its  infrastructure;  its  information  infrastructure  is  both  part  of  that 
infrastructure  and  representation  of  (the  key  elements  of)  it.  If  the  idea  is  that  the 
information  infrastructure  can  see  how  the  enterprise  can  change,  it  has  to  have 
reflection  in  its  own  definition,  dynamic  objects.  The  only  production  operating 
system  that  supports  this  is  NeXT.  Taligent  would  have  also. 

4A  model  kernel.  At  some  point,  you  need  to  normalize  the  way  you  represent 
the  environment  and  the  way  you  represent  information  services  in  that  environ¬ 
ment.  The  System  Object  Model,  SOM,  provides  this  in  addition  to  supporting 
more  mundane  implementation  necessities. 


10.3  What  WeVe  Done 


^  (Some  involvements  we  have  to  ensure  visibility  into  these  trends.) 

The  metrics  project  and  its  predecessors  have  supported  progress  in  all  these 
areas. 
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jiWeVe  supported  the  j  eries  of  interdisciplinary  meetings  called  Foundations  of 
Information  Science  (FI:;),  which  looks  at  fine-grained  self-organizing  agencies  as 
a  basis  for  adaptive,  sel  -sustaining  systems. 

^Weve  created  and  sup  ported  the  series  of  focused  workshops.  Business  Appli¬ 
cations  of  Situation  Theory  (BAST)  to  merge  agent  ideas,  communicative  acts,  sit¬ 
uation  theory  and  category  theory.  This  is  leveraged  through  the  pre-existing 

pular*^^*^(lTALLC)^'  f^/o/mot/on  Theoretic  Approaches  to  Language,  Logic  and  Com- 

<*We  had  a  hand  in  organizing  and  supporting  the  International  Society  for  the 
Interdisciplinary  Study  of  Symmetry  (ISIS-S)  to  bring  group  theory  to  general 
enterprise  representation  in  a  practical  way, 

4  We  play  a  role  in  the  International  Society  for  Group  Theoretic  Cognitive  Science, 
which  shares  the  few  results  in  group  theoretic  abstraction. 

^  We  established  and  managed  the  Suppliers’  Working  Group  (SWG)  which  played 
roles  in  encouraging  SOM  and  making  it  an  open  standard,  CORBA;  specifying 

the  reflective  language  Dylan;  and  reflective  enterprise  operating  system  Tali- 
gent. 
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11  Definitions 

|Key  definitions  of  the  project.| 

11.1  VE 

(Definitions  related  to  the  virtual  enterprise.] 

n  .1 .1  Enterprise  Versus  Corporation 

|Why  virtual,  why  enterprise.] 

Several  groups  use  many  of  the  terms  that  the  project  does,  but  sometimes 
mean  quite  different  things.  By  virtual,  we  do  not  mean  home  officing  of  employ¬ 
ees,  for  example.  In  the  few  sections  that  follow,  we  explain  what  we  mean,  and 
describe  why. 

Others  say  Virtual  Corporation  to  convey  what  we  mean  by  Virtual  Enterprise.  In 
neither  case  do  we  mean  that  it  is  not  real,  or  does  not  manufacture  real  products. 
What  is  intended  is  that  the  grouping  of  people  and  resources  has  no  collective 
identity  either  before  or  after  addressing  a  specific  opportunity.  It  is  in  a  sense  pro¬ 
miscuous  in  that  its  loyalties  and  the  cost  of  disassociating  are  low. 

Our  concise  definition  of  a  VE  is  a:  Temporary  aggregation  of  core  competencies 
and  associated  resources  collaborating  together  to  address  a  specific  situation,  pre¬ 
sumed  to  be  a  business  opportunity. 

We  have  chosen  to  use  Enterprise  rather  than  Corporation,  because  the  latter 
presumes  that  there  is  a  shared  vision  of  a  corporate  identity.  Enterprise  conveys 
the  meaning  that  the  shared  focus  is  the  work. 

Corporation  implies  a  conventional  organization  whose  control  is  centralized, 
which  is  not  what  we  mean.  The  VE  is  unified  by  its  mission  and  distributed  goals, 
not  its  control  system. 

n  .1 .2  Four  Types  of  VEs 

(We  allow  a  wide  variety  of  things  to  be  called  virtual  enterprises,  but  impose  a  basic  taxonomy  on  the  major 
types.] 

The  Virtual  Enterprise  is  defined  as  an  opportunistic  aggregation  of  entities  work¬ 
ing  toward  a  common  goal.  The  entities  could  be  individual  corporations,  separate 
divisions  in  a  corporation,  or  other  entities,  such  as  consumer  groups  or  labor 
unions.  Even  with  this  definition,  we  cover  a  lot  of  ground.  So  we’ve  broken  things 
down  into  smaller  categories. 

Several  different  types  of  aggregation  have  been  identified  which  range  from 
more  interesting  to  less  interesting.  The  more  interesting  engage  in  novel  business 
relationships  which  involve  risk  and  reward.  An  attempt  has  been  made  to  incor¬ 
porate  all  of  the  different  views,  in  a  set  of  definitions  that  represent  four  types: 

4Type  1 :  An  aggregation  formed  in  response  to  an  opportunity.  In  its  pure  form, 
this  is  the  prototypical  (and  most  interesting)  type  where  an  entity  identifies  an 
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1 .  Opportunity-driven 

2.  Capability-driven 

3.  Supplier  Chain  (topdown) 

4.  Bidding  Consortium 


No  pure  cases  seem  to  exist 
Best  practices  may  be  of  different  type 
Types  may  differ  between  formation  and  operation 


Figure  1 1-1:FourTypes  of  Virtual  Enterprises 

opportunity  (or  recognizes  a  change)  which  takes  advantage  of  a  core  compe¬ 
tency.  Then  an  entity  (normally  the  one  which  recognizes  the  opportunity)  acts  as 
organizer  to  identify  and  creatively  Integrate  partners  with  complementary, 
required  core  competencies. 

4Type  2:  A  relatively  permanent  aggregation  of  core  competencies  that  largely 
pre-exists,  and  which  is  seeking  an  opportunity.  Generally,  new  members  must  be 
brought  into  the  partnership  in  order  to  address  the  opportunity.  Large  corpora¬ 
tions  are  often  examples  of  this  type  when  they  have  many  perceived  core  com- 
petencies. 

4Type  3:  A  supplier  chain  which,  while  using  relatively  conventional  business 
relationships,  exhibits  agility  in  responding  to  market  needs.  Electronic  Com¬ 
merce  also  fits  into  this  group  when  it  employs  traditional  (albeit  automated) 
business  transactions. 

4Type  4:  A  bidding  consortium.  Such  a  group  relies  on  relatively  conventional 
business  relationships  in  its  interactions.  But  it  employs  agile  practices  in 
response  to  market  needs,  and  it  acts  as  a  Virtual  Enterprise  in  representing  col¬ 
lective  capabilities  to  a  customer. 

^  One  perspective  holds  that  Type  2  is  a  special  case  of  Type  1 ,  differing  only  in 
the  emphasis  on  the  search  for  the  opportunity  and  possibly  the  granularity  and 
importance  of  the  central  core  competencies.  Another  view,  not  in  contradiction, 
suggests  that  each  type  can  be  cast  in  terms  of  an  agile  supplier  chain  or,  alterna- 
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tively,  electronic  commerce.  Considering  AVE  types  in  this  light  helps  envision 
growth  paths  from  a  current,  less  virtual  situation. 

Each  of  the  four  types  could  result  in  Virtual  Enterprises  which  are  useful  and 
profitable  but  not  agile.  The  Agile  Virtual  Enterprise  (AVE)  is  one  that  simply  re¬ 
sponds  well  (at  low  time  and  cost)  to  unexpected  change.  As  a  rough  discriminator, 
however,  a  Virtual  Enterprise  is  an  AVE  if  it  is  formed  with  the  intent  of  dissolving 
or  quickly  and  cheaply  reconfiguring  in  direct  response  to  a  change  in  the  oppor¬ 
tunity. 

Of  the  four  types,  the  latter  two  are  less  agile  and  virtual.  The  discriminator  is 
the  ability  of  each  component  to  change  the  way  it  does  business  within  the  con¬ 
text  of  the  AVE.  For  example,  a  supplier  chain  relies  on  well-established  bound¬ 
aries  to  guide  the  way  it  integrates  into  the  system.  If  the  supplier  were  capable  of 
realigning  by  having  shared  employees  and  supervisors  (if  that  were  beneficial),  it 
would  be  more  like  a  Type  1 .  There  is  a  large  class  of  actions  which  could  be  taken 
to  integrate  processes.  For  that  reason.  Type  3  AVEs  tend  to  look  more  like  Type 
1  s  as  they  become  more  agile.  Similarly,  Type  4s  aspire  to  be  Type  2s.  Supply 
chains  can  exist  in  any  of  the  types. 

In  our  surveys,  we  found  that  few  real  world  cases  cleanly  fit  these  types.  All 
were  some  combination;  some  were  more  one  type  in  formation  and  another  in 
operation.  In  other  cases  best  practice  was  beneficial  because  they  adopted,  for 
that  process,  a  personality  which  was  of  a  different  type  AVE. 

11.2  AVE 

[Definitions  related  to  agility.] 


1 1 .2. 1  Definition  of  Agility 

[Agility  deals  with  change.) 

A  dominant  definition  of  the  agile  enterprise  is  one  which  responds  to  (and  ide¬ 
ally  benefits  from)  unexpected  change.  Unexpected  is  a  key  word;  the  ability  to 
build  in  response  to  expected  change  in  the  manufacturing  domain  has  tradition¬ 
ally  been  termed  flexible  manufacturing,  as  distinct  from  agile  manufacturing.  But 
it  would  be  possible  to  have  a  flexible  enterprise  without  having  an  agile  one.  (The 
same  is  true  of  a  lean  enterprise.) 

The  Virtual  Enterprise  is  usually  defined  as  an  opportunistic  aggregation  of  busi¬ 
ness  units  which  operates  in  important  ways  as  if  it  were  a  single  company.  Many  ver¬ 
sions  of  the  VE  exist.  Probably  a  VE  is  agile  only  if  it  is  formed  with  the  intent  of 
dissolving  or  reconfiguring.  So  it  is  possible  to  have  a  VE  without  having  an  AVE. 

The  Agile  Virtual  Enterprise  (AVE)  is  an  important  instance,  a  model  for  planning 
an  agile  strategy  for  many  enterprises.  Obviously,  no  organization  can  afford  to  be 
ready  for  ail  contingencies.  A  given  firm  will  need  to  partner  with  others  to  bring 
^core  competencies  to  bear  in  response  to  unexpected  situations. 

Each  of  the  four  types  of  VE  could  result  in  Virtual  Enterprises  which  are  useful 
but  not  agile.  The  AW  is  often  thought  of  as  one  that  exhibits  a  critical  number  of 
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characteristics,  developed  by  the  Agility  Forum,  which  describe  agility.  As  a  rough 
discriminator,  however,  a  Virtual  Enterprise  is  an  AVE  if  it  is  formed  with  the  intent 
of  dissolving  or  quickly  and  cheaply  reconfiguring  in  direct  response  to  a  change 
in  the  opportunity. 

More  particularly,  there  are  a  number  of  conditions  which  can  change  and  affect 
an  enterprise.  An  agile  response  might  be  required  concerning  a  negative  change 
as  well  as  to  address  a  positive  opportunity.  For  example,  a  positive  opportunity 
would  be  a  newly-identified  customer  niche,  or  a  leveragable  technology.  A  nega¬ 
tive  change  may  be  a  new  restrictive  law,  a  raw  material  which  disappears,  or  a  cus¬ 
tomer  who  has  been  enticed  away. 

1 1.2.2  Agility  as  Creativity 

|An  agile  organization  is  a  creative,  learning  one.| 

Notwithstanding  the  definition  given  above,  there  are  a  number  of  other  inter¬ 
locking  definitions  of  agility,  each  of  which  has  utility  to  some  community.  Cur¬ 
rently,  the  Forum  uses  a  concept  of  mass  customization,  a  more  general  definition 
than  we  address. 

We  add  one  more  general  concept,  an  intuitive  definition:  agility  as  creativity. 
The  purpose  is  not  to  supplant  any  of  the  others,  but  instead  to  provide  an  intui¬ 
tive  equivalent  to  other  characteristics  intuitively  applied  (such  as  better,  faster, 
cheaper). 

An  ideal  enterprise,  virtual  or  not,  is  a  living,  creative  entity.  It  is  both  self-con¬ 
scious  and  also  aware  of  its  environment,  and  it  is  capable  of  creatively  responding 
to  changes  either  inside  or  outside.  In  this  sense,  the  agility  of  an  enterprise  is  the 
capability  to  be  creative. 

As  the  metrics  project  developed,  the  nature  of  the  agility  paradigm  became 
more  clear.  A  few  have  known  for  some  time  that  agility  is  a  radical  new  paradigm. 
It  represents  not  an  evolutionary  new  step  of  another,  now  well  accepted  para¬ 
digm  like  lean  manufacturing.  Instead,  it  can  be  regarded  as  revolutionary. 

Being  cheaper,  better,  and  faster  today  is  not  sufficient  to  be  agile.  It  can  be  the 
case  that  moves  made  to  make  one’s  enterprise  cheaper,  better,  and  faster  may 
make  it  less  agile. 

Agility  is  the  ability  to  change  to  be  cheaper,  better,  and  faster  (more  profitable) 
in  a  dynamic  sea  of  change. 

This  recognition  of  agility  as  a  new  paradigm  is  not  without  consequence.  Met¬ 
rics  to  work  with  agility  will  be  a  new  kind  of  metric;  it  just  won't  do  to  rely  only 
on  existing  measures.  (Notwithstanding  this,  the  metrics  need  to  map  to  profitabil¬ 
ity  as  defined  by  the  enterprise’s  strategy.) 

It  probably  is  also  the  case  that  at  least  in  some  situations,  the  new  types  of  met- 
irics  for  the  new  paradigm  will  require  new  technology  and  forms  of  non-technical 
infrastructure. 
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1 1 .2.3  Types  of  Agility 

(Considerations  of  who  is  agile,  and  who  benefits.) 

Agility  of  a  component  in  the  VE  can  be  analyzed  as  follows: 

4 1 .  Characterization  of  what  it  does 

4 1  .a.  What  it  adds  to  the  whole 
4 1  .b.  What  it  makes 

42.  Characterization  of  how  good  it  is 

^2.a.  internal  agility 

42.b.  Internal  performance  (other:  quality,  etc.) 

^3.  Characterization  of  how  well  it  partners 

^3.a,  In  a  static  situation  (to  respond  to  initial  change) 

^3.b.  In  a  dynamic  situation  (to  respond  to  continual  change) 

If  one  were  creating  an  information  base  on  potential  partners,  it  should  gather 
these  six  types  of  information,  each  with  a  temporal  modifier.  The  modifier  may 
record  how  the  baseline  information  is  compromised.  For  instance,  normally  a 
partner  may  be  capable  of  supplying  1000  widgets  a  month,  but  they’ve  just 
booked  a  big  job,  so  now  only  have  the  available  capability  to  produce  500. 

Agility  can  be  temporally  modified.  Say,  for  example,  that  the  supplier  has  just 
entered  into  an  agile  situation  with  Ford.  That  means  that  sense-response  mecha¬ 
nisms  are  attuned  to  the  Ford/supplier  context.  So  its  ability  to  be  agile  in  a  part¬ 
nership  with  CM  could  be  temporally  compromised,  until  the  VE  with  Ford  is 
dissolved. 

Overall,  there  are  these  four  contexts  for  agility: 

^Sum  of  internal  agility  of  each  of  the  components 
^The  (probably  quite  different)  agility  of  the  VE  as  a  whole 
^The  ability  of  each  component  to  quickly/cheaply  aggregate 

^The  ability  of  each  component  to  quickly/cheaply  change  the  aggregation 
boundary 

There  is  a  layering  here;  there  are  higher  and  lower  orders  of  agility.  It  is  possi¬ 
ble  for  a  firm  to  be  agile  internally,  but  to  not  be  able  to  agily  form  a  VE,  or  con¬ 
tribute  agility  to  the  If  that  is  the  case,  the  firm  may  have  agility  appropriate  to 

its  local  plan,  but  it  is  of  a  low  order. 

Much  better  is  the  type  of  internal  agility  that  contributes  to  external  agility, 
agility  with  your  partners.  In  the  four  contexts,  the  following  nesting  exists,  each 
a  dependent  subset  of  the  preceding: 

^The  ability  of  each  component  to  quickly/cheaply  change  the  aggregation 
boundary 

,  ^The  ability  of  each  component  to  quickly/cheaply  aggregate 
^Sum  of  internal  agility  of  each  of  the  components 
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This  is  to  say  that  the  agility  of  the  VE  comes  from  the  ability  of  each  component 
to  be  added,  or  subtracted,  and  to  fluidly  change  its  relationship  with  the  partners, 
plus  the  skill  of  the  VE’s  organizer.  (Some  will  prefer  to  see  the  organizer  as  the  VE 
engineer.)  So  in  order  to  measure  agility,  we  should  be  looking  at  the  boundaries 
among  components  and  the  internal  processes  which  support  them.  That  is  our 
target  for  the  metrics. 

The  other  contexts  for  agility  are  of  a  lower  order.  It  would  be  possible  to  satisfy 
them  well,  without  supporting  the  higher  orders. 

Incidentally,  this  leads  us  to  a  controversy  in  the  agility  community.  Some  hold 
that  agility  is  something  that  can  mean  a  great  deal,  just  within  a  single  company 
context.  Others  suspect  that  to  be  true,  but  also  believe  that  a  much  greater  re¬ 
ward  (more  scope  at  less  cost  and  time)  from  agility  comes  only  from  its  VE  con¬ 
text. 

We’ve  come  around  to  the  latter  perspective,  and  now  believe  that,  in  any  case, 
agility  in  the  VE  context  is  substantially  cheaper  and  much  more  effective  than  in¬ 
ternal  agility. 

1 1 .2.4  Other  Agility  Definitions 

|Our  definition  is  exclusive  to  change,  but  others  use  the  term  more  broadly.) 

Whenever  a  rich  idea  finds  a  time  that's  right,  it  proliferates  in  poorly  behaved 
ways.  We've  seen  it  in  the  software  community  as  object  orientation  has  caught  on 
and  essentially  taken  over.  There  are  many  definitions  of  what  constitutes  the  ap¬ 
proach  and  its  philosophy  and  on  first  sight,  they're  all  nearly  identical.  But  the 
deeper  one  goes,  the  more  different  they  seem. 

In  our  studies,  we've  experienced  the  same  thing  with  patterns  and  memes.  In 
each  case,  there  is  not  a  central  idea,  but  a  collection  of  ideas  living  under  one  gen¬ 
eral  buzzword.  Often  there  are  few  real  concepts  which  unite  the  collection. 

Agility  is  such  a  rich,  timely  concept. 

We  initially  had  some  trouble  with  the  definition  of  agility  because  we  naively 
were  looking  for  a  single  common  thread  among  all  the  researchers,  instead,  we 
now  believe  there  are  three  concepts  of  agility  co-existing  under  the  word  (and  as¬ 
sociated  sponsored  research).  All  are  useful,  but  to  a  large  degree  are  orthogonal. 

The  first  definition's  central  concept  is  mass  customization,  and  supporting 
ideas  like  being  close  to  the  customer  (pro>nding  solutions).  Levi's  is  agile  because 
they  can  make  custom  fitted  jeans;  Mack  because  a  large  part  of  their  business  is 
unique  trucks.  Let's  call  that  A'. 

The  second  definition,  A^,  covers  companies  which  thrive  in  change.  But  change 
here  is  a  constant  in  the  environment.  It  could  be  seen  as  changerate,  and  often  is 
driven  by  technology.  Avionics  businesses  must  be  agile  because  technology  devel- 
|Opment  makes  products  obsolete  at  an  increasing  rate.  Casio  is  agile  because  cus¬ 
tomers  want  mouse  watches  yesterday,  waterproof  watches  today,  and  lighted 
watches  tomorrow;  in  this  case,  the  changerate  is  driven  by  the  customer. 
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We're  using  the  term  changerate,  so  as  not  to  step  on  MITs  term,  clockspeed, 
and  also  to  make  an  observation.  Clockspeed  can  be  interpreted  as  the  rate  of  the 
instrument  rather  than  of  the  phenomenon  being  measured.  In  our  modest  work 
we've  found  that  both  are  important.  The  general  case  is  the  speed  of  the  context. 

A'  is  a  new  way  of  doing  business,  and  probably  has  the  largest  pool  of  enter¬ 
prises  to  which  it  applies.  It  Is  revolutionary,  if  it  Is  a  real  phenomenon,  and  there 
should  be  lots  of  opportunity  for  consulting,  assessments  and  training.  Mo.st  ev¬ 
eryone  will  want  to  explore  it  and  many  will  want  to  pursue  it.  The  Agility  Forum 
has  grown  into  A\ 

A^  is  a  logical  evolution  of  lean  for  businesses  whose  changerate  is  high.  Lean 
was  difficult  to  understand  in  a  meaningful,  applicable  way;  we  should  expect  no 
less  of  its  future.  A  large  percentage  of  the  agility  community  are  A^ers,  including 
the  university-based  centers  and  projects,  in  particular  the  Agile  Manufacturing  Re¬ 
search  Institutes,  Arizona  State  and  MIT. 

That's  good.  There  is  a  lot  of  Important  thinking  going  on  here.  A^  agility  is  only 
of  interest  to  high  clock  rate  sectors  of  enterprises,  probably  a  smaller  group  than 
that  which  can  benefit  from  A’.  But  while  the  user  community  for  A^  is  smaller,  agil¬ 
ity  is  probably  essential  for  their  survival. 

But  wait.  Is  the  future  of  an  agile  avionics  or  missile  supplier  as  they  come  to 
terms  with  changerate  in  mass  customization?  Probably  not.We  think  A’  and  A^ 
have  some  overlap,  but  it  is  largely  an  almost  accidental  and  uninteresting  result 
of  the  fact  that  most  businesses  have  similarities. 

A2  agility  deals  with  an  expected  and  constant  (or  constantly  accelerating)  type 
of  change.  Laptop  manufacturers  have  a  high  changerate,  but  the  rate  of  change  is 
predictable  (although  the  details  of  new  technologies  are  not).  It  would  be  possible 
for  a  firm  to  optimize  Its  ability  to  deal  with  this  expected  change  and  actually  less¬ 
en  its  ability  to  deal  with  unexpected  change. 

Similarly,  A’  doesn't  help  with  unexpected  change  or  opportunities.  Mack  Truck 
is  considered  A’  agile,  but  can  it  make  money  supplying  major  subassemblies  to 
Caterpillar  when  a  construction  boom  hits?  Can  they  easily  leverage  a  core  compe¬ 
tency  in  truck  cab  sleepers  to  move  Into  combat  tank  sleepers  if  an  opportunity 
hits? 

The  money  for  Levi's  may  not  be  In  jeans.  It  might  be  in  custom  measuring  of 
shoes,  or  something  else.  They  could  be  surprised  by  what  the  opportunity  is. 
Does  furthering  A’  or  A^  increase  their  ability  to  change  in  these  unexpected  ways? 

We  can  easily  invent  examples  where  A’  and  A^  act  against  this  adaptability. 
There  is  a  third  kind  of  agility,  A^,  which  concerns  itself  with  adaptability,  the  abil¬ 
ity  to  change  when  an  unexpected  opportunity  appears,  or  if  the  earth  shifts  be¬ 
neath  your  feet. 

A^  has  a  much  smaller  community  for  whom  it  is  a  major  concern:  most  business- 
►es  never  know  the  opportunities  they  miss  and  few  believe  in  buying  insurance 
against  change  until  it  Is  too  late.  This  is  the  most  revolutionary  agility.  Certainly 
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it  has  the  most  challenging  set  of  problems;  measuring  an  ability  to  adapt,  to  learn, 
is  no  easy  matter. 

is  of  concern  in  the  defense  sector.  We  know  we  need  to  counter  a  threat, 
but  we  know  neither  what  the  threat  is  nor  what  technology  will  be  available.  And 
we  have  found  many  in  the  civil  sector  who  are  looking  for  agility  without  nec¬ 
essarily  calling  it  agility. 

Our  metrics  are  in  the  A^  area,  and  it  is  only  in  that  area  that  the  metrics  apply. 
It  is  our  view  that  Rick  Dove's  early  work  (DOVE95],  and  Kenny  Preiss's  work  on  dy¬ 
namically  coupled  systems  is  pure  A^.  (PGN96) 

There  are  three  relatively  unrelated  concepts  each  with  their  own,  independent 
act  under  the  agility  bigtop.  This  realization  has  helped  us  a  lot  in  interrelating  the 
various  research  efforts. 

1 1 .2.5  Role  of  the  Organizer 

(One  partner  is  an  organizer,  who  has  additional  agility  concerns,  how  agily  it  can  organize  or  coordinate  orga¬ 
nization.] 

The  competence  of  the  organizer  Is  key  to  the  general  success  as  well  as  the  agil¬ 
ity  of  the  VE.  While  the  organizer  is  often  a  prime,  there  is  no  requirement  for  this. 
It  could  be  a  minor  player  in  the  operation,  or  someone  with  no  role  in  the  oper¬ 
ation,  such  as  a  broker  or  consultant. 

As  noted,  agility  in  the  VE  is  dependent  on  the  contributions,  of  different  types, 
from  each  of  the  members.  But  it  also  depends  on  the  special  ability  of  the  orga¬ 
nizer  to  engineer  and  manage  that  potential. 

The  other  players  have  one  set  of  metrics  for  how  agily  they  can  be  organized. 
The  orpnizer  may  have  another  set  pertaining  to  how  well  it  can  organize  an  AVE. 
This  will  be  a  partnering  consideration  for  everyone  involved,  because  surely  an  in¬ 
dicator  of  success  is  the  strength  of  the  VE  integrator. 

These  organizer  metrics  are  not  difficult  to  understand  and  use:  they’ll  be  simi¬ 
lar  to,  and  in  most  cases  identical  to,  metrics  which  currently  are  used  to  evaluate 
the  ability  to  engineer  or  re-engineer  an  organization.  Our  metrics  will  not  directly 
measure  this  organizer’s  ability.  We  measure  the  potential  that  Is  there,  but  not 
the  manager’s  ability  to  maximize  that  potential. 

It  could  be  that  there  is  no  central  entity  that  is  the  organizer.  Perhaps  the  or¬ 
ganizing  entity  is  itself  a  virtual  entity  composed  from  several  sources  which  may 
or  may  not  be  involved  in  the  operating  VE.  Perhaps  the  entitles  are  self-organiz¬ 
ing,  the  organizer  being  diffused  in  rules.  Some  Silicon  Valley  VEs  are  of  this  type. 
The  Whaling  example  has  some  elements  of  this  type. 

An  interesting  case  Is  when  the  customer  is  the  organizer.  Naturally,  the  options 
listed  above  are  available.  Any  of  these  cases  can  be  ideal  from  a  market  respon¬ 
siveness  point  of  view,  assuming  that  the  customer  is  the  best  judge  of  what  is 
needed.  (But  there  is  ample  evidence  that  this  is  at  least  not  always  the  case.) 
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We’ve  noted  that  the  Defense  AVE  is  unique  in  the  role  that  the  customer  (mean¬ 
ing  the  DoD  acquisition  manager)  plays  in  the  AVE.  This  is  the  sole  area  in  which 
the  commercial  and  defense  AVEs  differ.  Because  of  the  importance  of  the  Defense 
AVE,  we  will  further  explore  some  of  those  organizer  issues. 

1 1 .2.6  Types  of  Change 

[Different  changes  require  different  types  of  agility.) 

The  metrics  must  have  two  parts:  the  context  of  the  change  and  a  measure  of  the 
effectiveness  of  the  strategy  to  respond.  Usually,  change  is  categorized  into  the  fol¬ 
lowing  five  groups,  often  associated  with  a  state  diagram: 

^Resources 

^Technology 

^Processes  (internal  conditions  and  mechanisms) 

^Environment  (external  conditions  and  mechanisms) 

4 Demand  (customer  conditions  and  mechanisms) 

Often,  agility  is  considered  in  the  context  of  change  in  the  customer  base.  But 
we’ve  discovered  a  larger  set  of  contexts  of  change.  It’s  assumed  that  we  need  to 
measure  agility  in  any  of  these  five  categories,  and  that  there  is  no  particular  level 
of  importance. 

We’ve  changed  this  model  to  consider  technology  as  a  resource.  This  is  because, 
for  our  target  customers,  agility  is  not  a  response  to  technological  innovation,  but 
instead  is  a  business  response  which  might  be  empowered  by  technology.  The  as¬ 
sumption  doesn’t  ignore  technology,  but  requires  that  it  always  be  evaluated  as  a 
resource. 

A  minority  objects  to  this  view.  It  is  easily  demonstrable  that  technology  is  the 
major  driver  of  change.  We  agree.  Technology  in  this  model  refers  only  to  technol¬ 
ogy  which  supports  the  enterprise.  This  use  of  technology  has  not  traditionally 
been  a  driver  of  change  except  in  the  context  of  the  other  factors.  For  example, 
technology  empowers  certain  types  of  customer  demands. 

The  boundaries  among  the  last  three  (processes,  environment,  demand)  niay  in¬ 
dicate  a  difference  between  agility  in  the  virtual  enterprise  and  in  the  non-virtual 
enterprise  (single  firm).  In  a  single  firm  those  boundaries  are  solid  and  well  under¬ 
stood.  In  the  VE  those  boundaries  (and  possibly  those  of  resources)  are  blurred  and 
movable.  At  the  least,  it’s  assumed  that  internal  and  external  conditions  and  mech¬ 
anisms  have  no  real  boundary  and  instead  represent  a  spectrum. 

So  one  set  of  metrics  will  address  the  ability  to  move  boundaries  beneficially  in 
a  VE:  for  example, 

^to  make  an  external  resource  internal 

^to  harmonize  an  external  disruption  by  incorporating  internally  (to  empower 
)  unions  in  the  enterprise,  for  example),  or 

ito  damp  customer  oscillations  by  bringing  them  into  the  enterprise  in  some 
way.  These  would  not  apply  to  the  non-VE  case. 
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External  Processes 


Laws  and  l^e^ulations 

Internal  Processes  of  Your  Partner 


Resources 

Intellectual  Prop^^l 
Technology 
Paw  Materials 
Commodities 


internal  Processes 

Your  Business  and 
Workflow  Processes 


Customer  Demand 


Customer  Expectations 
Market  Niches 


Figure  1 1-2:Unexpected  change  (positive  or  negative)  can  come  from  any  of  the  four 

key  areas 


A  Positive 
Example 

A  Negative 
Example 

Unexpected  Down¬ 
stream 

Customer  Behavior 

New  Niche  Identi¬ 
fied 

Customer’s  expec¬ 
tations  change 

Unexpected 

Upstream 

Material  Change 

New  Raw  Material 

Disastrous  Loss  of 
Raw  Material 

Unexpected  Inter¬ 
nals 

Process  Change 

New  Process  Devel¬ 
oped 

A  Key  Expert  Retires 
or  Dies 

Unexpected  Exter¬ 
nals 

Reguiation/Partner 

Change 

New  Competitive 
Tools 

New  Regulatory 
Demand 

Table  11-1:  Some  Examples 


It  is  also  evident  that  agility  may  be  pursued  for  some  strategic  reason  that  is 
not  prompted  by  an  external  or  uncontrollable  change.  Perhaps  some  strategic 
reason  appears,  for  example,  one  might  want  to  move  agily  to  partner  with  a  com¬ 
pany  to  prevent  their  abilities  from  going  to  a  competitor.  While  this  would  fit  in 
the  above  view,  it  would  not  appear  if  the  only  driver  were  cost  and  time. 
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12  Metrics 

[Considerations  relating  to  what  the  metrics  themselves  are.] 

In  other  sections,  we’ve  defined  what  constitutes  a  VE,  what  agility  is  and  what 
it  isn’t.  We  now  turn  to  the  nature  of  the  metrics  required  to  address  the  engineer¬ 
ing  of  AVEs.  This  section  breaks  down  the  various  characteristics  required  of  the 
metrics  to  support  that  engineering/management  process. 

12.1  What  Are  We  Measuring? 

|We  don't  measure  what  you  did,  but  what  you  are  (likely)  capable  of  doing.] 

The  term  metrics  is  applied  to  a  number  of  situations.  What  do  we  mean? 

To  others,  a  metric  is  a  measure  of  improvement.  In  this  case,  some  technology 
and/or  management  technique  is  brought  to  bear  to  accelerate  the  change.  Retro¬ 
spectively,  one  observes  that  some  element  of  the  VE  is  improved,  for  example, 
partner  selection  is  speeded,  or  engineering  change  processes  are  reduced.  The 
comparison  of  the  improved  situation  with  a  similar,  but  unimproved  one  results 
in  a  measure  of  effectiveness.  This  is  a  retrospective  measure.  We  do  not  address 
this  situation. 

At  the  shop  floor  level,  the  term  is  often  applied  to  characterize  the  perfor¬ 
mance  or  envelope  of  a  given  equipment  or  cell.  Thus  there  are  a  class  of  metrics 
which  track  improvements  on  processes  which  managers  routinely  use.  Many 
quality-related  metrics  are  of  this  type.  Our  metrics  are  not  the  same  as  these,  but 
there  are  similarities  to  many  of  these  metrics  that  are  derived  not  from  observa¬ 
tion,  but  by  exercising  some  model  of  the  process  and  are  parametric. 

Another  class  of  distinctly  different  metrics  are  metrics  that  measure  the  cost, 
time,  and  quality  of  processes  not  associated  with  change.  An  example  is  the  met¬ 
ric  which  measures  the  time-to-market.  Another  class  of  metric  deals  with  how 
cheaply,  well,  and  fast  an  enterprise  or  VE  can  do  things.  Our  metrics,  which  only 
measure  the  time  and  cost  of  change,  will  be  combined  with  these  base  case  bet¬ 
ter-faster-cheaper  metrics  to  determine  the  total  time  and  cost  associated  with  the 
whole  system  under  conditions  of  change. 

So  if  a  company  merely  improves  its  existing  processes,  which  it  might  consider 
as  a  change,  our  metrics  would  not  apply,  since  we  do  not  consider  a  refinement 
of  a  process  an  ability  to  respond  to  change.  In  fact,  by  our  definition,  no  agility 
measure  applies. 

In  another  case,  if  a  company  exhibited  agility  in  the  past  in  response  to  change, 
our  metrics  still  might  not  apply,  since  past  agility  indicates  nothing  or  very  little 
about  future  agility. 

Our  metrics  address  only  the  time  and  cost  associated  with  the  potential  that  a 
system  has  to  accommodate  future  change. 

12.2  Upstream  Metrics 

[We  measure  in  a  fashion  that  can  indicate  what  needs  to  be  done  to  improve  agility.) 
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The  kind  of  metrics  the  AVE  needs  are  upstream  metrics  rather  than  downstream 
metrics. 

A  downstream  metric  is  the  conventional  kind,  related  to  benchmarking.  It  looks 
at  a  process  and  extracts  some  performance  measure  from  it  for  example  for  mon¬ 
itoring  the  process.  When  the  measures  are  compared  to  a  large  body  of  similar 
processes,  one  process  can  be  benchmarked  against  the  others,  and  management 
decisions  made  accordingly.  But  continuity  in  the  context  is  essential. 

Downstream  metrics  don't  convey  knowledge  about  the  internal  workings  of 
the  process,  so  they  cannot  tell  one  how  to  improve  the  process,  only  that  the  pro¬ 
cess  needs  to  change  somehow  to  improve  the  number.  Moreover,  since  there  is 
an  assumption  that  the  future  will  be  extrapolated  from  the  past,  they  tell  us  little 
about  adaptability  in  a  new  context. 

Upstream  metrics  are  based  on  the  internal  mechanics  of  the  process.  An  under¬ 
standing  of  the  metric  is  based  on  the  understanding  of  the  process.  Upstream 
metrics  can  answer  questions  that  a  manager/planner  may  have  about  how  to  im¬ 
prove  the  process. 

There  is  a  precedence  for  these  kinds  of  metrics  in  manufacturing  based  on  an 
engineering  analogy  applied  to  physical  processes.  The  project  applied  this  meth¬ 
od  across  all  of  the  elements  in  the  VE  associated  with  agility  and  identified  by  the 
Reference  Model.  This  will  be  done  by  understanding  the  causes  and  effects  of  agil¬ 
ity,  as  if  models  of  the  system  were  simulated. 

As  with  upstream  and  downstream  metrics,  there  is  a  similar  division  with  the 
models  that  support  them. 

Some  models  are  used  to  only  evaluate  the  enterprise,  or  some  part  of  it.  The 
analysis  is  performed  and  the  model  is  discarded,  unless  of  course  the  analysis  is 
continuous  and  the  model  must  be  maintained.  But  there  is  a  more  robust  class  of 
models,  those  used  to  actually  control  the  enterprise.  There  is  a  relationship  be¬ 
tween  the  control  model  and  our  upstream  metrics.  The  best  situation  would  be 
for  us  to  directly  work  from  and  contribute  to  the  control  model. 

Some  have  confused  this  notion  of  upstream  metrics  with  metrics  of  leading  in¬ 
dicators,  common  in  process  industries.  But  it  is  a  much  more  powerful  idea;  lead¬ 
ing  indicators  only  give  you  a  warning  of  impending  change  assuming  that  your 
experience  base  is  robust  and  conditions  are  known.  But  the  do  not  tell  you  why 
things  will  change. 


12.3  Necessary  Conditions 

(We  do  not  assume  that  there  are  any  agility  strategies  that  fit  all  conditions.} 

Some  agility  metrics  might  be  based  on  necessary  conditions.  But  we  intend  to 
extract  those  conditions  as  a  result  of  the  principles  involved  and  their  metrics, 
rather  than  the  other  way  around. 

For  example,  some  contend  that  flat  organizations  are  necessary  for  agility. 
Based  on  that  assumption,  they  derive  a  measure  of  flatness  and  apply  it  to  agility. 
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This  is  the  case  of  a  class  of  metrics  often  used  by  the  agility  community,  in  our 
opinion  mistakenly. 

Instead,  the  metrics  project  came  to  a  more  basic  understanding  of  what  really 
results  in  agility.  One  would  expect  that  in  many  situations,  the  resulting  metrics 
would  advise  flattening  of  the  organization.  But  the  exceptions  to  this  rule  of 
thumb  are  many.  How  would  you  know  whether  they  apply  to  you  if  you  didn't 
know  how  it  produced  agility? 

Insight  into  actual  processes  would  emerge  by  applying  the  metrics.  More  im¬ 
portantly,  a  chain  of  logic  would  be  established  that  helps  Justify  high  confidence 
decisions. 

12.4  Dynamism  of  Metrics 

[These  metrics  are  hard  because  they  measure  the  control  over  dynamic  coupling.  Agility  is  like  insurance.] 

Most  metrics  are  static.  They  report  on  a  factor  in  a  snapshot  sense. 

Agility  is  a  potential  to  make  change  in  response  to  change.  It  reports  on  a  capa¬ 
bility  that  projects  current  capabilities  in  today's  context  into  a  new  set  of  capabil¬ 
ities  in  another  context.  Therefore,  the  metric  will  be  dynamic. 

All  such  metrics  will  be  collections  of  interrelated  numbers.  One  collection  will 
convey  the  dynamic  nature  of  the  changing  capability.  Another  will  show  how  that 
collection  can  be  accelerated  or  delayed  at  different  costs  and  for  different  times. 
Because  of  this,  there  may  be  a  concept  of  acceleration  or  inertia. 

In  other  words,  the  metric  takes  into  account  the  running  start  an  enterprise 
may  have. 

Agility  metrics  are  different  than  many  other  metrics  in  the  manufacturing  en¬ 
terprise.  Flexible,  Lean,  and  Quality  paradigms,  for  example,  presume  that  there  is 
always  a  better  level  of  flexibility,  leanness,  or  quality  which  would  help  the  enter¬ 
prise.  The  optimum  level  Is  a  trade-off  between  better  quality  {for  example)  and  its 
marginal  cost. 

Agility  follows  this  rule  to  a  point.  In  ways  that  an  enterprise  needs  agility,  there 
is  always  a  cost/benefit  balance  that  metrics  can  Inform.  But  there  is  another  set  of 
trade-off  points,  where  further  levels  of  agility  are  not  good,  and  in  fact  might  hurt 
an  enterprise’s  strategy. 

Agility  is  insurance,  and  investment  decisions  need  to  be  made  accordingly.  It  is 
possible  to  have  too  much  insurance  (or  the  wrong  kind).  The  ability  to  accommo¬ 
date  a  change  that  is  unimportant  or  unlikely  to  occur  represents  the  wasting  of 
resources.  So  where  quality  mavens  can  say  that  there  is  never  too  much  quality, 
we  cannot  say  the  same  for  agility. 

12.5  Difficulty  of  Benchmarking 

^  |The  metrics  bear  no  relation  to  benchmarking  measures.  Agility  may  not  be  benchmarkabie.] 

Elsewhere,  we  have  distinguished  between  upstream  metrics  and  downstream 
metrics.  Examples  of  downstream  metrics  were  benchmarks.  The  intended  mean- 
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ing  of  benchmark  there  was  an  after-the-fact  snapshot  metric  whose  utility  is  in 
comparing  to  other  snapshots.  In  making  the  distinction,  It  was  assumed  that  up¬ 
stream  metrics  are  more  difficult  because  they  require  insight  into  the  actual  pro¬ 
cesses  Involved,  whereas  downstream  metrics  do  not. 

But  there  is  a  more  fundamental  difference,  not  captured  earlier.  Agility  is  de¬ 
fined  as  the  potential  to  respond  well  to  unexpected  change.  Any  metric  that  is  use¬ 
ful  tracks  that  potential.  A  downstream  metric  can  do  no  better  than  measure  how 
well  a  process  (or  an  enterprise  as  a  collection  of  processes)  responded  to  a  spe¬ 
cific  change. 

So  a  downstream  metric  might  have  some  utility  for  application  to  a  process  In 
order  to  benchmark  it  against  Itself  But  in  order  to  be  useful  to  another  process 
in  another  organization,  a  thorough  normalization  must  take  place,  making  sure 
the  process  and  the  general  context  is  similar  between  the  two  cases,  including  the 
specific  unexpected  change. 

Here’s  where  we  run  into  difficulty.  Benchmarking  as  commonly  applied  is  the 
process  of  comparing  many  companies,  identifying  the  best  in  class,  and  then  pre¬ 
sumably  comparing  your  organization  with  the  purpose  of  Improvement.  Some 
benchmarks  indicate  the  process  to  change,  but  most  don’t  give  insight  into  the 
actual  mechanics  of  the  change. 

Benchmarking  assumes  that  there  is  a  well  understood  set  of  characteristics  that 
are  being  benchmarked  and  that  there  is  a  meaningful  sample  size.  Unfortunately, 
many  people  are  under  the  impression  that  various  lists  from  the  Forum  constitute 
that  set  of  characteristics.  Instead,  those  lists  contain  either  characteristics  that 
people  think  are  likely  to  coincide  with  agility,  or  that  were  results  of  agile  action. 

Examples  of  the  first  are  modular  processes,  flat  organizations,  empowered  indi¬ 
viduals,  etc.  It  may  be  that  implementing  these  characteristics  may  generally  make 
most  enterprises  more  agile,  but  It  is  also  clear  that  these  are  not  the  primary  en¬ 
gines  of  response.  Examples  of  the  latter  are  the  ability  to  retool  a  particular  piece 
of  equipment.  So  we  lack  the  prime  starting  point  of  conventional  benchmarking. 

Elsewhere  it  is  noted  that  more  agility  is  not  necessarily  better.  The  convention¬ 
al  benchmarking  paradigm  assumes  units  where  the  case  with  the  most  units  is 
best  in  class. 

All  of  these  perspectives  on  agility  suggest  that  agility  is  a  paradigm  that  falls 
outside  of  the  scope  of  paradigms  that  can  be  addressed  by  conventional  bench¬ 
marking.  In  particular,  agility  is  the  ability  to  react.  Any  measure  of  reaction  must 
capture  the  context  {ideally  itself  In  measured  units)  of  the  situation  to  which  the 
enterprise  is  reacting. 

Instead  of  conventional  benchmarking,  agility  must  look  for  a  better  way  of  ac¬ 
complishing  quantitative  assessment,  one  that  understands  both  the  context 
(which  might  be  unique  from  case  to  case)  and  the  effectiveness  of  the  response. 

►  It  is  an  open  issue  whether  there  is  any  such  thing  as  a  downstream  metric  for 
agility  which  differs  in  substance  from  the  upstream  metric.  This  is  probably  the 
same  question  as  whether  the  upstream  metrics  of  this  project  are  sufficient  for  a 
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new  paradigm  of  quantitative  assessment.  We  think  probably  not,  but  in  any  case 
quantitative  assessment  to  satisfy  the  benchmarking  agenda  is  outside  of  the 
scope  of  our  approach.  All  downstream  metrics  are  probably  going  to  measure  the 
effectiveness  of  the  tactic  used  to  respond  and  not  the  strategy  which  drives  it. 

12.6  Two-part  Metrics 

(Each  response  has  to  take  into  consideration  the  nature  of  the  change  to  which  it  is  responding-! 

The  project  is  geared  toward  providing  a  single  generic  metric  type,  and  guide¬ 
lines  (and  examples)  for  tailoring  them  to  specific  processes  via  the  Reference 
Model  where  information  about  agile  decisions  is  desired.  All  of  these  generic  and 
specific  metrics  will  be  two-part. 

The  first  part  will  characterize  the  context  in  which  the  agility  is  posed.  The  sec¬ 
ond,  more  simple  part  characterizes  the  response  in  cost  and  time.  In  other  words, 
agility  is  the  ability  or  capability  to  change  well  (in  terrns  of  cost  and  time)  in  a  giv¬ 
en  set  of  conditions.  So  the  project  has  always  to  provide  the  measure  of  the  re¬ 
sponse  in  the  context  of  a  measure  of  the  stimulus.  This  will  allow  for  connection 
with  simulation  as  well. 

The  context  problem  raises  many  vexing  problems,  owing  to  the  diversity  in¬ 
volved.  The  project  gets  a  handle  on  context  by  relying  on  a  close  understanding 
of  what  discrete  infrastructure  mechanics  are  involved.  It  may  be  that  many  of  the 
contexts  are  characterized  in  terms  of  constraints. 

Two  of  the  established  concepts  to  understand  agility  are  scope  and  robustness. 
Scope  refers  to  how  large  a  domain  is  covered  by  the  agile  response  system.  In  oth¬ 
er  words,  how  far  from  the  expected  set  of  events  can  one  go  and  still  have  the 
system  respond  well.  The  other  concept,  robustness,  is  a  measure  of  how  well  the 
system  responds,  given  a  specific  scope.  These  two  go  together  naturally. 

They  can  be  envisioned  as  a  three-dimensional  bump  on  a  plane.  The  plane  rep¬ 
resents  the  universe  in  which  the  system  operates.  The  height  of  the  bump  is  the 
robustness  of  the  system.  The  nature  of  the  peak  is  not  of  interest  here,  but  as  one 
gets  farther  away  from  the  peak,  the  system's  designed  focus,  the  robustness  tails 
off  and  becomes  flat. 

The  project  characterizes  several  characteristics  of  this  hill.  But  in  almost  all  cas¬ 
es,  the  width  of  what  can  be  addressed  within/by  a  single  company  is  vastly  less 
than  can  be  addressed  if  VE-type  partnering  is  agily  available.  Both  the  height  and 
area  covered  are  very  much  greater  (over  an  order  of  magnitude  on  some  scale) 
greater  if  the  VE  is  part  of  the  agility  solution. 

Therefore,  we  believe  that  the  more  interesting  case  for  understanding  and  har¬ 
nessing  agility  is  the  AVE  context. 

12.7  Quantitatively  Scalable 

7  [To  be  useful,  the  metrics  need  to  be  numbers  calculated  from  the  process,  not  subjectively  determined.) 
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Scope;  how  many  'ypes  of  change  are  covered 

- ^ 


Robustness: 
radical  a  change  the 
response  can 
fully  address 


Plane  Defines  enterprise’s  environment 

Planar  dimensions  are  types  of  change  (somehow  parameterized) 

Figure  12-1  :The  parameterized  agility  of  an  enterprise  can  be  seen  as  a  curve  over 

a  plane 

The  metrics  are  quantitative,  that  is,  naturally  based  in  numbers.  This  contrasts 
with  subjective  evaluations  which  currently  characterize  the  study  of  agility. 

They  are  formally  based,  meaning  that  there  is  a  well-established  link  with  the 
management  and  information  sciences  involved.  Different  persons  evaluating  the 
same  process  using  the  same  methods  will  produce  identical  values. 

These  values  are  denominated  in  standard  units  which  are  commonly  used  and 
carry  intuitive  value  to  the  manager.  An  unsophisticated  manager  can  understand 
the  metric,  while  a  sophisticated  manager  should  be  able  to  audit  the  underlying 
mechanics  all  the  way  to  the  enterprise’s  strategic  measures  of  profitability  and 
strength. 

We  can  distinguish  three  concepts  of  scaling  in  the  metrics. 

^The  metrics  of  interest  are  not  process-dependent,  nor  linked  to  any  specific 
granularity  of  processes.  In  other  words,  it  should  not  matter  whether  the  metric 
is  applied  at  the  level  of  an  individual  process  (fine  granularity)  or  at  a  coarser 
level  such  as  a  cell  or  line.  The  square  feet  metric  as  an  Indicator  of  lean  is  a  good 
example:  it  applies  equally  from  the  individual  process  to  the  factory;  the  fewer 
square  feet  a  process  has  the  more  lean  it  is. 

A  example  of  a  metric  which  does  not  scale  is  quality.  The  sum  of  many  quality 
processes  does  not  necessarily  result  in  a  quality  system. 

^Second,  the  metrics  scale  horizontally  as  well,  across  functions.  It  is  useful  that 
the  enterprise  can  be  evaluated  by  the  same  metrics  regardless  of  whether  it  is  a 
*  shop-floor  process  or  an  administrative  service. 

^Third,  the  metric  is  internally  linear,  without  discontinuous  thresholds.  In  other 
words,  the  difference  between  a  3  and  a  4  is  the  same  as  the  difference  between 
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a  4  and  a  5.  It  should  not  be  the  case  that  at  some  threshold  within  an  interval, 
the  improvement  is  radical. 

Of  them,  the  first  is  most  important  and  the  others  are  highly  desirable. 

In  addition  to  the  caveat  noted  above,  there  may  be  a  barrier  to  the  scaling  when 
the  process  leaves  the  individual  corporate  boundary  of  the  individual  entity.  For 
example,  square  feet  as  an  indicator  of  lean  may  become  relatively  meaningless 
when  applied  collectively  to  several  companies  in  VE  partnership. 

This  is  to  say  that  there  might  be  different  metrics  or  constraints  used  to  mea¬ 
sure  agility  of  a  component  than  to  measure  the  agility  of  the  VE.  In  particular,  the 
following  types  of  measures  may  be  used: 

^Metrics  of  agility  within  a  component  (a  partner); 

^Metrics  of  the  agility  the  component  brings  to  the  VE; 

^Metrics  of  the  agility  of  the  component  within  the  VE;  and 
^Metrics  of  the  agility  of  the  VE  seen  as  a  whole. 


Aggregate  VE 


Figure  12-2:Agility  Within'Entities,  Among  Entities,  and  of  the  System 


Because  of  the  above  differences  in  focus,  there  may  be  a  different  set  of  metrics 
or  a  different  context  to  metrics  used  by  the  organizing  entity  than  by  partners  be¬ 
ing  organized. 

In  particular,  the  scaling  limit  is  probably  traceable  to  when  the  representations 
of  the  features  which  characterize  agility  (transactions)  are  turned  into  numbers. 
In  the  tactical  case,  the  numbers  themselves  are  useful.  But  a  simple  combination 
of  the  numbers  does  not  convey  the  same  amount  of  information  as  a  combination 
of  the  representations  which  underlie  them.  This  is  the  traditional  systems  optimi¬ 
zation  problem:  a  simple  sum  of  agile  components  may  not  result  in  an  agile  sys¬ 
tem. 

This  is  why  we  use  a  scenario-based  conversation  breakdown  to  capture  two  el- 
^ements  of  agility  for  a  process  in  each  Reference  Model's  cell:  the  intrinsic  agility 
of  the  process,  and  the  agility  contribution  to  the  system. 
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12.8  Legacy  vs.  Heritage 

(An  optimal  agile  response  not  only  accomplishes  the  change,  but  does  so  in  a  way  that  increases  your  agility 
for  the  next  time,  probably  different.) 

The  nature  of  agility  is  anticipatory.  Where  cheaper,  faster,  and  better  deal  with 
the  situation  today,  agility  (and  its  little  brother,  flexibility)  deal  with  the  situation 
(ability  to  be  profitable)  tomorrow.  Naturally,  the  focus  on  the  ability  to  change 
turns  into  profit  today  very  quickly,  how  quickly  being  a  part  of  the  metric. 

The  relationship  between  profit  today  (as  captured  in  lean  manufacturing  for  ex¬ 
ample)  and  ogH/fy  tomorrow  Is  an  interesting  and  complex  one.  A  similar  relation¬ 
ship  exists  between  legacy  as  opposed  to  heritage  infrastructure. 

Usually,  the  re-engineering  process  converts  the  as-is  situation,  often  called  a 
legacy,  into  a  to-be  system.  Under  this  view,  the  legacy  represents  a  barrier,  a  col¬ 
lection  of  problems.  Once  the  as-is  becomes  achieved,  ail  will  be  well.  But  agility 
deals  with  establishing  the  capability  to  change  to  a  large  and  constantly  changing 
set  of  as-is  conditions. 

It  is  useful  therefore  to  define  two  classes  of  legacy:  the  legacy  which  exists  be¬ 
fore  a  re-engineering  change  Is  made  (using  the  new  term,  heritage)  and  the  legacv 
which  exists  afterwards.  ^ 

The  heritage  is  what  you  inherit  from  others,  for  better  or  worse.  Much  of  the 
game  involves  identifying  strengths  and  weaknesses  in  this  heritage  and  develop¬ 
ing  an  appropriate  strategy.  A  legacy  is  the  heritage  that  you  create  for  the  future, 
the  next  folks,  with  Its  own  strengths  and  weaknesses.  Ideally,  the  legacy  you  leave 

will  be  more  self-aware  and  capable  of  leveraging  itself  than  the  heritage  you  are 
given. 

The  metrics  of  the  project  are  targeted  toward  understanding  the  heritage  in 
such  a  way  to  improve  the  legacy  in  its  ability  to  change  itself  beneficially. 

12.9  Environmental  Drivers 

(There  likely  are  some  external  conditions  within  which  enterprises  and  partners  exist  that  will  tend  to  make 
them  more  agile  than  without  those  conditions.) 

The  metrics  of  course  advise  decisions.  But  one  would  expect  that  they  would 
Indicate  generic  strategies  as  well.  For  instance,  it  seems  to  be  a  tenet  of  VEs  that 
(under  normal  circumstances)  capital  investment  should  be  focused  on  core  com¬ 
petencies  and  away  from  skills  that  can  be  obtained  by  partnering.  The  metrics 
should  reinforce  and  clarify  the  limits  of  obvious  principles  such  as  these,  but  they 
should  also  indicate  less  intuitive  general  principles. 

One  secondary  area  where  general  principles  would  be  useful  is  In  the  area  of  a 
VE  Promoting  Environment.  Clearly,  some  environmental  factors  can  make  it  easier 
for  the  type  of  partnering  that  drives  interesting  VEs.  Such  environmental  factors 
^spontaneously  appeared  to  support  the  whaling  industry  and  may  be  in  place  to¬ 
day  to  some  extent  in  Silicon  Valley.  It  is  not  the  purpose  of  the  project  to  under¬ 
stand  these  dynamics;  perhaps  a  follow  on  effort  by  others  is  indicated.  But 
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certainly,  the  behavior  indicated  by  the  metrics  should  shed  light  on  the  nature  of 
this  environment. 

For  example,  much  has  been  made  of  the  legal  difficulties  associated  with  the 
VE.  Some  maintain  that  legal  barriers  are  intransigent  limiters,  preventing  interest¬ 
ing  Type  1  AVEs  from  forming.  These  people  maintain  that  a  necessary  condition 
for  a  VE  Promoting  Environment  is  the  legislative  resolution  of  these  and  related 
issues  (such  as  intellectual  property  rights  and  security). 

We  would  expect  the  metrics  to  help  indicate  alternative  approaches  to  these 
seemingly  insurmountable  barriers.  Early  thinking  has  already  indicated  some  ex¬ 
ample  threads  worth  following  in  the  legal  infrastructure. 

The  standard  response  to  VE  legal  agreements  is  to  try  to  generate  generic,  plug 
and  play,  instant  contracts.  But  it  is  clear  that  such  instruments  either  will  be  over¬ 
ly  restrictive  in  the  business  relationships,  or  obese.  The  FAR  (Federal  Acquisition 
Regulations)  were  generated  with  just  this  lofty  goal  ofan  instant,  generic  contract 
in  mind.  Such  thinking  is  dragging  federal  acquisition  back  to  the  middle  ages. 

Instead,  suppose  one  focused  on  a  set  of  ethical  principles  for  arbitration,  if 
these  were  solidly,  simply  based,  they  could  form  the  basis  for  resolving  issues  as 
they  arise,  instead  of  resolving  all  possible  issues  ahead  of  time.  This  tactic  could 
allow  for  VE-empowering  lightweight  agreements.  It  is  also  a  tactic  that  the  U.  S.'s 
significant  international  competitors  cannot  implement  as  well  because  we  use 
case  law  instead  of  their  code-based  laws.  Case  law  is  based  on  this  tradition,  but 
has  been  obscured.  The  whaling  example  reinforces  this  point). 

Another,  related  problem  deals  with  trust.  Often,  the  primary  purpose  of  a 
heavyweight  contract  is  to  mitigate  distrust,  and  a  large  component  of  that  deals 
with  liability.  In  fact,  the  issue  is  who  has  to  pay  for  liability  insurance  (either  ex¬ 
plicit  or  internal)  to  cover  which  conditions.  The  legal  barrier  here  actually  resolves 
to  a  technical  requirement.  What  is  needed  are  VE-sensitive  actuarial  tools  to  em¬ 
power  a  VE  liability  insurance  business.  Probably,  this  would  allow  the  insurance 
company  to  become  a  member  of  the  VE. 

12.10  Strategic  Links 

[The  metrics  need  to  support  the  differing  parameters  used  in  strategic  planning.  Those  are  noted.] 

All  intelligent  enterprises  will  have  a  strategy,  which  represents  a  balance  of 
profitability  today  and  profitability  tomorrow.  The  latter  is  a  measure  of  strength 
and  will  be  a  mix  of  the  following: 

^Customer  Goodwill 
^Core  Competency  Development 
^Intellectual  Property 
^Market  Share 

f  ^Employee  Development 
^Stockholder  Value 

(Each  of  these  has  dependencies  with  the  others.) 
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In  the  future,  Agility  will  be  added  to  this  list.  Until  it  is,  every  metric  that  is  de¬ 
veloped  in  the  project  must  have  a  direct  chain  of  logic  from  the  individual  appli¬ 
cation  of  the  metric  to  either  immediate  profitability  or  some  mix  of  that  and  the 
six  listed  above. 

Early  in  the  project,  it  was  thought  that  this  chain  of  logic  could  be  shortened. 
The  reason  is  that  the  top  level  metrics  (profitability  and  the  six  strength  metrics) 
would  have  already  been  supported  by  a  strategy.  The  strategy  would  have  been 
supported  by  a  set  of  strategic  metrics. 

Strategic  metrics  are  of  the  type: 

^Correct  Product 
4  Cost 
^Quality 
^ Cycle  Time. 

Since  the  logic  chain  was  presumed  to  exist  between  these  four  and  the  top  level 
metrics,  it  seemed  sufficient  to  make  the  new  agility  metrics  relate  only  to  the 
four. 

But  it  has  subsequently  been  determined  that  agility  is  substantially  different 
than  the  static  strategies  which  support  the  four  strategic  metrics.  This  difference 
is  discussed  elsewhere. 

(The  sequence  of  Correct  Product,  Cost,  Quality,  and  Cycle  Time  represents  the 
historical  sequence  that  these  have  become  accepted  as  useful  strategies.  The  met¬ 
rics  applied  are  listed  in  the  same  sequence  elsewhere:  cheaper,  better,  faster.) 

So  the  challenge  is  to  provide  a  clear  chain  of  logic  from  each  of  the  new  metrics, 
all  the  way  up  to  the  top  level  profitability  and  strength  metrics. 

12.1 1  Rules  of  Thumb 

(Repeated  use  of  the  metrics  will  result  in  some  rules  of  thumb  that  won't  need  the  expense  of  calculating  num¬ 
bers.) 

We  believe  that  many  decisions  that  a  manager  encounters  will  be  identical  or 
similar  to  situations  encountered  by  others.  After  a  period  of  time  and  experience 
with  the  metrics,  certain  rules  of  thumb  will  emerge.  We  consider  these  rules  of 
thumb  to  be  among  the  best  potential  long  term  products  of  the  project.  Managers 
can  apply  these  rules  of  thumb  without  going  through  the  effort  of  evaluation  by 
the  metrics. 

We  expect  the  Agility  Forum  to  provide  a  service  to  the  domestic  economy  by 
collecting  these  rules  of  thumb  in  an  easily  accessible  case  base. 

Many  smart  people  have  been  meeting  and  talking  about  agility  for  some  years 
now.  Some  intuitive  results  have  emerged.  For  example,  many  people  feel  that  the 
^more  flat  an  organization  is,  or  the  more  empowered  the  work  force  is,  the  more 
agile  the  enterprise  will  be.  This  is  probably  true  in  many  cases,  but  clearly  not  in 
all  cases. 
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Application  of  the  metrics  would  be  expected  both  to  verify  these  intuitive  sus- 
picions  and  (more  importantly)  to  Indicate  the  scope  within  which  they  apply,  and 
the  limits  of  application. 


Figure  12-3:Rules  of  Thumb  Can  Be  Extracted  from  Several  Steps  in  the  Process 
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13  Agility  and  Other  Approaches 

jThere  are  other  beneficial  trends  underway.  How  does  agility  relate  to  them?) 

13.1  Agility  Forum  and  Agility 

|Our  work  complements  that  of  the  Forum  without  much  overlap.) 

We  use  traditional  Agility  terms  where  appropriate.  But  it  is  important  to  note 
the  few  differences  that  might  exist  with  assumptions  of  prior  work  and  work  by 
others. 

The  Agility  Forum  oyer  the  past  four  years  has  developed  different  sets  of  de¬ 
scriptive  terms  for  agility.  Some  of  those  sets  are  more  popular  than  others.  It 
might  be  beneficial  for  our  metrics  if  straightforward  links  with  those  terms  and 
concepts  were  made  and  we  have  done  so  below.  It  certainly  will  register  the  met¬ 
rics  better  with  those  accustomed  to  using  those  terms. 

Problems  arise,  since  the  many  existing  terms  are  general  and  not  formally  def¬ 
initional.  That  is,  it  is  possible  to  find  examples  which  fit  all  the  terms  but  are  not 
examples  of  A3  agile  systems. 

In  one  set  of  definitions  1PGN96|,  the  Forum  uses  the  following  four  character¬ 
istics  to  define  agility: 

^Solutions  Provider 
^Collaborative  Production 
^Reconfigurable  Organization 
^Knowledge-Driven  Enterprise 

These  characteristics  don’t  discriminate  between  agile  and  non-agile  cases  with 
sufficient  crispness  on  which  to  base  the  formal  metrics  studies.  Therefore,  we’ve 
defined  here  our  view  of  agility  which  could  be  considered  pure  agility,  A^,  which 
we  think  is  a  subset  of  what  the  Forum  has  taken  as  its  charter.  The  difference,  we 
believe,  is  simply  that  we’ve  avoided  the  many  good  business  practices  that  are  not 
unique  to  agility,  the  ability  to  respond  to  change. 

Nonetheless,  the  AVE  Focus  Group  worked  to  make  a  mapping  from  the  Life  Cy¬ 
cle  Dimension  of  the  AVE  Reference  Model  to  descriptors  that  the  Forum  has  de¬ 
veloped  for  A1  Agility: 

^1.1  Opportunity  Strategy 

^Intensifying  Competition 
Rapidly  Changing  Markets 
Increasing  Capable  Communication  Technologies 
High  Rate  of  Innovation 
Decreasing  New  Product  Time-to-Market 
^Fragmentation  of  Mass  Markets 
,  Growth  of  Niche  Markets 

Shrinking  Product  “Windows” 

^Cooperative  Business  Relationship 
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Increasing  Inter-Enterprise  Cooperation 

Increasing  Outsourcing 

Global  Sourcing/Marketing/Distribution 

^Solutions  Provider 

Niche  Marketer:  High  Product  Density 

High  Product  Introduction  Rate 

Rapid  Concept-to-Cash 

Production  to  Order 

Solution-Based  Marketing  Policies 

^Adaptive  Organizations 

Coordinated,  Decentralized  Decision-Making 

Change  Proficient  Organization 

4 Knowledge-Driven  Enterprise 

Dynamic,  Competency-Based  Strategic  Plan 

Enterprise-Centered  Operations 

Open  Information  Policies 

Open  Communication  Policies 

4 1 .2  Exposure 

^Cooperative  Business  Relationships 

Increasing  Inter-Enterprise  Cooperation 

Interactive  Value-Circle  Relationships 

^Solutions  Provider 

Proactive  Marketplace  Change  Agent 

^Collaborative  Operations 

Collaboration  =  Product  Strategy  of  First  Choice 

Electronic  Commerce  Operability 

^Cooperation 

Cooperation  with  Suppliers 

Cooperation  with  Customers 

4 1 .3  Targeted  Marketing 

^Cooperative  Business  Relationships 
Increasing  Inter-Enterprise  Cooperation 
Global  Sourcing/Marketing/Distribution 
^Demand  Identification/Creation 
Market  Research 
Product  Definition 

Product  Feasibility:  Realization  Strategy 
^Adaptive  Information  System 
^1.4  Search 

^Fragmentation  of  Mass  Markets 
Growth  of  Niche  Markets 
Shrinking  Product  Lifetimes 
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^Cooperative  Business  Relationships 
Increasing  Inter-Enterprise  Cooperation 
Interactive  Value-Circle  Relationships 
Increased  Outsourcing 
^Increasing  Societal  Values  Pressure 
Regulatory  Environment 
Workforce  Education 
Changing  Social  Contract 
^Adaptive  Organizations 
Timely,  Opportunity-Driven  Organization 
Adaptive  Information  System 
^Knowledge-driven  enterprise 
Corporate  Knowledge  Capture 
Open  Information  Policies 
Open  Communication  Policies 
42.1  Partner  Qualification 

^Cooperative  Business  Relationships 

4  Solutions  Provider 

Cost-Effective  Low-Volume  Producer 

Production  to  Order  Individualized  Products/Services 

Life  Cycle  Design  Methodology 

Open  Architecture  Product  Design  Philosophy 

Extraordinary  Quality  Standards 

^Collaborative  Operations 

Cooperation  =  Product  Strategy  of  First  Choice 

Concurrent  Operations 

Integrated  Product  and  Process  Development 

Virtual  Organization  Partnering 

Electronic  Commerce  Operability 

Proactive  Information  Sharing  Policies 

^Adaptive  Organizations 

Timely,  Opportunity-Driven  Organization 

Change  Proficient  Organization 

Adaptive  Information  System 

^Knowledge  Driven  Enterprise 

Open  information  Policies 

Open  Communication  Policies 

^Integration 

Real  Time  Management  Tools 
Comprehensive,  Distributed  Information  Access 
Support  for  Physically  Distributed  Teams 
^Flexibility 

d  Enterprise  Management 
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Supplier/Customer/Partner  Relations 
Knowledge  Assets 
Information  Systems 
^Metrics 

Rapid  Partnership  Formation 
Pre-qualified  Supplier  Certification 
42.2  Partner  Performance  History 
^Solutions  Provider 
Extraordinary  Quality  Standards 
^Collaborative  Operations 
Virtual  Organization  Partnering 
^2.3  Partner  Search 

4  Enterprise  Management 
Supplier/Customer/Partner  Relations 
Human/Physical/Financial  Resources 
Knowledge  Assets  Information  Systems 
^Collaborative  Operations 
Virtual  Organization  Partnering 
Electronic  Commerce  Operability 
^3.1  Vision/Strategy  Development 
^Intensifying  Competition 
^Cooperative  Business  Markets 
^Fragmentation  of  Mass  Markets 
4 Solutions  Provider 
^Collaborative  Operations 
^Knowledge-Driven  Enterprise 
^Integration 
^Cooperation 
^Enterprise  Management 
^Demand  Fulfillment 
^Metrics 

^3.2  Partner  Criteria  and  Selection 
^Collaborative  Operations 
^Adaptive  Organization 
^Integration 
^Cooperation 
^Enterprise  Management 

^3.3  Enterprise  Metrics 

^Knowledge-Driven  Enterprise 
^Integration 

^Enterprise  Management 
^Metrics 
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^3.4  Capitalization 

^Enterprise  Management 

^3.5  Product  Liabilities 

^Knowledge-Driven  Enterprise 
^Integration 
^Cooperation 
^Enterprise  Management 

^3.6  Risk/Reward  Strategies 

^Collaborative  Operations 
^Knowledge-Driven  Enterprise 
^Integration 

^Cooperation  Enterprise  Management 

^Demand  Fulfillment 

^Metrics 

43.7  Operating  Structure 

i Collaborative  Operations 
^Adaptive  Organization 
^Knowledge-Driven  Enterprise 
^Integration 
^Flexibility. 

^3.8  Dissolution 

4 Cooperative  Business  Relationships 
^Adaptive  Organization 
4  Reconfigurability 
^Enterprise  Management 
^Metrics 

^4.1  Performance  Measures 

^Collaborative  Operations 
^Adaptive  Organization 
^Knowledge-Driven  enterprise 
^Integration 
^Cooperation 
^Enterprise  Management 
^Metrics 

^4.2  Customer  Relations 

^Cooperative  Business  Relationships 
^Solutions  Provider 
^Collaborative  Operations 
4 Knowledge-Driven  Enterprise 
^Cooperation 
^Enterprise  Management 
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^Demand  Fulfillment 
^4.3  Operating  Practice 

^Cooperative  Business  Relationships 
4 Solutions  Provider 
^Collaborative  Operations 
^Knowledge-Driven  Enterprise 
^Cooperation 
^Enterprise  Management 
^5.1  Identification  of  Need 
^Solutions  Provider 
^Collaborative  Operations 
^Adaptive  Organization 
4  Knowledge-Driven  Enterprise 
^Integration 

^Cooperation  Enterprise  Management 
^Demand  Identification 
^Demand  Fulfillment 
^Metrics 

45.2  Residual  Liabilities 

^Knowledge-Driven  Enterprise 
^Enterprise  Management 
^Metrics 

^5.3  Asset/Equity  Dispersal 

^Enterprise  Management 
^Knowledge-Driven  Enterprise 
^Metrics 

13.2  Older  Agility  Forum  Work 

(Our  work  also  complements  a  separate,  earlier  thread  of  the  Forum's,  with  a  little  more  overlap.) 

Another  legacy  of  agile  terms  has  come  from  the  Forum-sponsored  Best  Agile 
Practice  Survey  of  1994  |DOVE95J.  This  vision  deals  primarily  with  manufacturing 
processes,  tools,  and  resources.  Social  and  business  process  issues  exist  only  to 
support  change  in  those  domains.  The  view  is  fine-grained,  focused  on  individual 
items,  practices,  and  tools.  An  implicit  assumption  in  this  vision  is  that  agility  is 
additive;  a  sum  of  agile  tools  and  methods  will  result  in  an  agile  enterprise. 

We  look  at  the  broader  context;  agility  concerns  any  type  of  enterprise,  though 
manufacturing  is  the  most  interesting.  Its  scope  includes  very  early  phases  in  the 
opportunity,  and  continues  as  late  and  as  deep  as  the  enterprise  reaches.  It  in- 
, eludes  all  processes,  not  just  those  related  to  manufacturing.  This  vision  looks  for 
systemic  principles  and  concerns  itself  with  agile  infrastructure. 
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A  useful  exercise  will  be  to  reconcile  the  se  two  approaches  through  the  metrics. 
As  a  preliminary  step,  the  te  *ms  of  the  Forum’s  Best  Agile  Practices  \nsion  need  to 
be  redefined  in  the  context  3f  our  results 

The  best  practices  study  used  four  dim  jnsions  of  agility.  These  describe  end 
benefits.  They  are: 

^cost 

^time 

^robustness 
^  scope 

We  find  great  value  in  these,  but  do  not  consider  the  four  items  as  being  in  the 
same  class.  We  ve  heard  strongly,  from  out  potential  user  base,  that  agility  metrics 
need  to  be  in  terms  of  the  time  and  cost  of  effecting  change.  The  other  two  dimen¬ 
sions  are  part  of  the  descriptions  of  the  context.  In  other  words,  we  expect  that  a 
manager  will  ask,  given  a  specific  context  (which  includes  scope  and  robustness), 
what  is  the  time  and  cost  of  a  specific  change. 

Time  and  cost  are  related  by  a  function,  so  one  of  these  will  also  be  a  constraint, 
depending  on  the  situation.  For  example,  the  manager  may  actually  want  to  know 
that  they  have  to  change  within  a  specific  time  period  and  context;  tell  them  the 
cost.  Our  use  of  the  term  context  is  intended  to  subsume  scope  and  robustness. 
Context  is  the  characterization  that  is  determined  by  strategic  studies  that  specify 
the  type  and  extent  of  agility  of  interest. 

For  example,  one  context  may  be  the  agility  associated  with  supplier  contract 
arrangements,  the  scope  being  the  ability  to  change  from  a  specific  small  number 
of  contracted  units  to  a  larger,  specific  number.  We  might  be  interested  in  the  agil¬ 
ity  of  that  context.  But  if  the  larger  number  were  twice  as  large,  a  different  scope, 
a  different  agility  metric  would  result.  (Incidentally,  we’ve  discovered  that  some 
things  which  are  agile  in  one  scope  are  comparatively  less  so  in  a  different  con¬ 
text.) 

With  this  understanding  of  scope,  the  time  and  cost  function  captures  the  no¬ 
tion  of  robustness. 

A  second  set  of  legacy  characteristics  from  the  Best  Agile  Practice  Study  is  called 
the  eight  change  domains  of  agility.  These  describe  characteristics  of  agile  tools 
and  methods.  They  are: 

creation 
^capacity 
^capability 
^reconfiguration 
Emigration 
E  performance 
E  improvement 
E recovery 
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Our  metrics  do  not  use  these  as  definitional  of  agile  systems.  Instead,  we  under¬ 
stand  these  to  be  expected  characteristics  in  certain  situations  as  brainstormed  by 
bright  people  based  on  intuition.  In  their  place,  we  expect  that  rules  of  thumb  will 
appear  from  use  of  the  metrics.  These  should  mirror  and  validate  the  cited  change 
domains  but  with  the  applicable  context. 

The  AVE  Focus  Group  has  mapped  the  Forum's  agility  attributes  to  the  Refer¬ 
ence  Model. 

13.3  Virtual  Manufacturing 

I  We  particularly  support  simulated  AVEs.J 

One  definition  ofVirtual  Manufacturing  (VM)  is  the  strategic  simulation  of  many 
options  within  a  manufacturing  enterprise  to  support  decisionmaking.  (Another 
definition  looks  at  fine-grained  manufacturing  processes  and  their  simulation  indi¬ 
vidually  for  local  optimization.) 

Clearly,  our  metrics  work  overlaps  the  enterprise-wide  view.  Historically,  an  in¬ 
terest  in  VM  was  what  led  us  to  the  metrics  project.  In  particular,  the  metrics  are 
projective.  That  means  that  the  projection  is  based  on  rules,  extrapolation,  or  sim¬ 
ulation.  The  latter  case  is  a  working  definition  of  VM  developed  by  an  Air  Force 
Manufacturing  Technology  industry  workshop:  VM  is  the  use  of  simulation  to  deter¬ 
mine  performance  and  change  via  high  confidence  models  with  parameters. 

We  feel  that  these  metrics  will  provide  a  missing  foundation  for  VM. 

13.4  Activity-Based  Costing 

[Activity  Based  Costing  is  irrelevant  to  agility.] 

There  is  quite  a  controversy  concerning  Activity  Based  Costing  (ABC)  and  agility. 
Some  believe  that  ABC  is  especially  well  suited  to  support  agility,  and  there  have 
been  DARPA  Agile  Research  contracts  let  which  support  this  view.  But  from  the 
perspective  that  has  been  emerging  through  the  metrics  work,  it  appears  that  ABC, 
as  conventionally  understood,  is  not  well  suited  to  aid  decisions  concerning  A3 
agility. 

Traditionally,  ABC  has  been  used  to  take  an  existing,  stable  enterprise  which  is 
well  understood  (or  understandable)  and  decompose  the  costs  in  a  more  meaning¬ 
ful  way  than  common  accounting  methods  allow.  The  result  can  then  be  used  as  a 
costing  method  to  derive  the  costs  of  existing  products  and  minor  variations  on 
them.  More  advanced  use  of  the  technique  can  allocate  time,  risk,  opportunity  and 
other  measures  under  the  more  general  rubric  of  Activity  Based  Management 
(ABM). 

ABM  shares  at  least  one  major  philosophical  point  with  agility:  the  emphasis  on 
the  activity  (or  process)  rather  than  on  a  functional  breakdown  of  the  enterprise. 
>The  latter  is  an  artifact  of  a  paradigm  quickly  becoming  obsolete.  The  commonality 
of  this  perspective  may  be  what  has  erroneously  brought  the  ABM  and  agility  com¬ 
munities  together.  Some  ABM-related  practitioners  use  a  transaction  analysis  par¬ 
adigm  that  is  very  close  to  what  is  used  in  the  AVE  project.  But  there  are  problems. 
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ABM  depends  on  the  ability  to  extrapolate  information  about  change  from  ex¬ 
isting  accounting-like  data.  At  the  simplest  level  this  fails  in  the  case  of  situations 
which  benefit  the  most  from  agility,  those  which  experience  radical  change.  And 
there  is  a  fundamental  reason  for  this:  ABM  extracts  its  numbers  before  the  analy¬ 
ses  are  performed.  The  original  causes  and  relationships  that  the  numbers  repre¬ 
sent  must  stay  still  in  a  sense. 

There  is  no  dynamism  in  these  numbers;  the  metrics  are  downstream  in  the 
sense  that  has  been  discussed.  Moreover,  they  are  retrospective.  Both  of  these 
mean  the  same  thing  in  the  agile  context.  The  measures  can  be  used  to  help  un- 
derstand  what  has  happened,  but  cannot  be  used  to  predict  the  results  of  the  ac¬ 
tivities  in  new  circumstances. 

An  upstream  agility  metric  must  allow  the  analysis  to  be  performed  on  the  co¬ 
gent  relationships  themselves  to  produce  numbers  which  are  of  the  cost  and  time 
type. 

It  has  been  noted  that  there  are  other  problems  as  well,  though  these  are  sec¬ 
ondary  in  some  sense,  since  the  above  noted  inadequacy  is  fatal;  ABM  depends  on 
accounting-like  measures  as  its  atomic  unit.  It  derives  costs  from  costs  as  it  were. 
But  it  is  very  difficult  atomically  to  derive  costs  from  implicit,  intangible,  tacit  ac¬ 
tivities  in  the  cultural  and  social  infrastructures.  Likewise,  it  is  difficult  to  accom¬ 
modate  non-deterministic  phenomenon  in  the  arithmetic  functions  which  form 
the  basis  of  ABM. 

But  the  cultural/social  infrastructure  is  one  of  the  essential  components  in  mak¬ 
ing  agility  and  the  VE  work.  The  ability  to  characterize  it  in  an  upstream  way  (un¬ 
derstanding  the  processes)  is  essential,  but  is,  for  structural  reasons,  outside  of  the 
capability  of  ABM. 

Because  atomic  transactions  are  captured  as  numbers,  losing  functional  con¬ 
tent,  ABM  methods  are  particularly  ill  suited  for  understanding  agility  in  the  infor¬ 
mation  infrastructure.  The  net  result  is  that  ABM  is  one  of  those  methods  which 
appear  to  be  useful  for  helping  one’s  enterprise  be  faster  and  cheaper,  and  proba¬ 
bly  better,  but  it  cannot  help  with  making  it  more  agile. 

ABC  could  support  agility.  Notwithstanding  the  structural  differences,  it  appears 
that  ABC  could  end  up  being  a  rule-of-thumb  tactic  in  supporting  certain  scopes  of 
agility.  For  example,  one  of  the  features  which  we  measure  is  the  difference  be¬ 
tween  how  transaction  process  boundaries  are  handled.  If  the  VE  type  is  3  (Suppli¬ 
er  Chain)  and  the  infrastructure  issue  under  consideration  is  business  processes, 
then  how  reward  (meaning  costs  in  this  context)  is  measured  means  a  great  deal. 

If  two  processes,  one  in  the  prime  and  one  in  the  supplier,  both  figure  their  re¬ 
ward  structure  the  same  way,  and  if  the  granularity  is  higher,  then  the  agility  will 
be  higher.  This  is  not  a  result  of  ABC  per  se;  at  least,  it  is  not  the  need  for  which  it 
was  created.  Instead,  it  is  a  result  of  ABC  being  the  same  on  both  sides  (as  well  as 
being  consistent  and  being  true). 
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13.5  Lean  Manufacturing 

[Lean  and  agile  manufaauring  are  siblings,  but  being  one  doesn't  necessarily  result  in  the  other.] 

Other  agility  workers  have  proposed  that  Lean  Manufacturing  and  Agile  Manu¬ 
facturing  are  cut  from  the  same  cloth.  But  that  does  not  appear  to  be  the  case.  The 
Chrysler  example  is  just  one  example  and  weVe  found  extensive  confirmation  in 
industry. 

Lean  focuses  on  profitability  today.  Therefore,  it  works  to  lower  costs,  and  pos¬ 
sibly  to  reduce  time  of  current  product  portfolios.  Improving  quality  does  not  ap¬ 
pear  to  be  an  intrinsic  result  of  lean,  but  a  result  of  concurrent  adoption  of 
complementary  quality  Initiatives. 

Agile  focuses  on  profitability  tomorrow,  with  the  realization  that  tomorrow  be¬ 
comes  today  all  too  soon.  So  it  focuses  on  the  ability  to  change  to  improve  cost, 
time,  and  quality. 

Lean  is  static,  Agility  dynamic.  Our  Best  Agile  Practice  study  discovered  many 
cases  where  lean  and  agile  decisions  were  contradictory.  By  making  the  operation 
lean,  often  the  agility  seed  corn  is  eaten. 

A  high  value  area  is  the  overlap  between  the  two.  For  example,  many  observers 
believe  that  flat  organizational  structures  serve  both  philosophies.  (It  appears  to 
be  true  that  flatness  is  an  agile  strategy  in  many  contexts.) 

This  is  interesting  because  there  appear  to  be  some  agile  moves  an  organization 
will  make  which  will  cost  money  (or  involve  some  other  kind  of  compromise),  and 
some  will  be  free,  a  by-product  of  invoking  some  more  near-term  oriented  best 
management  practice. 

The  real  value  of  the  metrics  will  be  in  understanding  the  costs  and  benefits  of 
agile  decisions  that  are  not  freebies.  This  may  in  many  instances  involve  making  a 
business  case  for  deviating  from  lean  decisions  in  the  direction  of  agile  decisions. 

In  making  this  analysis,  we’ve  used  the  following  understanding  of  lean: 

^in  the  physical  and  workflow  area  (Physical  Infrastructure),  Lean  means  JIT  (just 
in  time) 

iin  the  business  practices  area  (Legal/Regulatory  Infrastructure),  Lean  means  flat 
organizations 

^in  the  cultural  area  (Cultural/Social  Infrastructure),  Lean  means  empowered, 
motivated  workforce 

^in  the  information  area  (Information  Infrastructure),  Lean  means  client-server 
models  and  standard  representations. 

One  difference  between  lean  and  agile  is  how  they  originated.  Lean  resulted 
from  a  focused  survey  of  what  was  the  apparent  discriminator  for  extraordinarily 
successful  enterprises  (in  the  automobile  sector).  The  term  lean  fits  some  of  the 
^practices  Intuitively  ^ust-in-time  workflows,  flat  organizations,  and  a  decreased 
supplier  base)  and  came  to  be  applied  to  others  as  well  (Total  Quality  Manage¬ 
ment,  empowered  workforce,  and  a  focus  on  customer  needs). 
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As  a  result  of  this  origin,  lean  practices  do  not  derive  from  any  underlying  phi¬ 
losophy,  and  they  involve  known  methods  and  support  technologies.  Agility  is 
quite  different.  It  originated  from  an  intensive,  several-month  workshop  of  busi¬ 
ness  executives  who  were  concerned  with  a  specific  need  that  they  knew  to  be  of 
immense  importance  to  survival,  for  which  they  lacked  existing  methods  and  un¬ 
derlying  technology.  So,  by  definition,  agility  goes  beyond  current  knowledge.  Un¬ 
like  lean,  all  agile  methods  result  from  a  common  underlying  vision-namely,  the 
ability  to  thrive  when  faced  with  change. 

Each  community  has  claimed  the  other  as  a  subset,  but  we  believe  that  agility 
has  the  stronger  claim  as  being  more  evolved.  Certainly,  a  complex  relationship  ex¬ 
ists  between  the  two: 

A  compelling  argument  can  be  made  (and  it  has)  that  agile  is  a  logical  evolution 
of  lean.  It  can  also  be  argued  that,  in  many  dimensions,  lean  and  agile  are  contra¬ 
dictory;  several  clear  examples  are  available.  Yet  a  third  proposal  Is  that  each  is 
equally  apt  and  modern,  but  they  address  quite  different  needs.  Lean  optimizes 
processes;  agile  optimizes  the  ability  to  adapt  processes  to  new  conditions.  This 
view  emphasizes  the  reinforcing  similarities  between  the  two. 

This  issue  has  no  effect  on  the  metrics.  We  believe  all  three  views  have  some 
merit.  Often,  the  difference  boils  down  to  religious  preferences,  or,  more  reason¬ 
ably,  strategic  goals  of  the  enterprise.  Equally  often,  the  views  depend  upon  the 
communities  of  interest. 

WeVe  come  to  believe  that  some  sectors  are  understandably  less  concerned 
with  agility  than  others.  This  makes  sense,  because  some  sectors  are  currently 
more  stable  than  others.  The  commercial  aircraft  and  automotive  sectors,  for  in¬ 
stance,  have  a  very  large  dependent  constituency  (airlines,  auto  repair,  and,  in  both 
cases,  travelers).  Their  product  models  take  a  long  time  to  develop  and,  once 
ready,  are  replicated  many  times.  New  models  are  always  evolutionary  in  almost 
every  respect. 

Sectors  more  likely  to  recognize  agility  as  important  include  the  defense  missile 
community,  entertainment,  certain  vertical  markets  for  computers,  and  all  soft¬ 
ware.  So  while  lean  is  of  interest  to  many  sectors,  agility  is  of  interest  to  a  smaller 
set.  But  in  those  cases,  it  is  more  likely  to  be  important. 

13.6  Flexible  Manufacturing 

(Flexible  manufacturing  is  an  (uninteresting)  special  case  of  agility.) 

The  difference  between  agile  manufacturing  and  flexible  manufacturing  is  more 
straightforward.  Flexible  is  a  subset  of  agile.  In  particular,  flexibility  is  agility  lim¬ 
ited  to  the  physical  infrastructure. 

When  we’re  talking  about  flexible  cells,  processes,  warehouses  and  even  rela¬ 
tionships,  we  generally  mean  to  focus  on  the  capital  investment.  Unfortunately, 
•many  of  the  examples  of  agility  which  have  appeared  are  of  physical  agility,  so  can¬ 
not  be  differentiated  from  flexibility,  which  is  not  very  revolutionary  or  even  new. 
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Those  examples  do  not  constitute  interesting  situations  so  far  as  the  metrics  are 
concerned. 

13.7  Electronic  Commerce 

lElearonic  Commerce  and  agility  are  largely  unrelated.) 

Substantial  excitement,  and  consequent  investment  in  development,  has  fo¬ 
cused  on  Electronic  Commerce  (EC).  Some  of  this  work  has  been  called  agile.  Our 
position  is  that  essentially  any  business  relationship  can  be  termed  a  VE.  We’ve 
tried  to  capture  the  difference  between  interesting  and  uninteresting  VEs.  The  dif¬ 
ferentiator  between  interesting  novel  VEs  (Types  1  and  2)  and  relatively  uninter¬ 
esting  ones  [3  and  4)  is  that  the  former  use  new,  novel,  fundamentally  different 
types  of  business  relationships. 

If  all  EC  does  is  lower  the  cost  or  time  of  conducting  business  in  conventional 
ways,  for  example  advertising  and  ordering  via  internet,  then  the  order  of  agility 
that  can  be  accommodated  is  low.  In  order  to  be  interesting,  party  A  should  be 
open  to,  for  instance,  having  party  B’s  supervisors,  equipment,  workers,  equip¬ 
ment  or  processes  intermingled  with  their  own  in  some  creative  way  so  that  the 
VE,  in  that  area,  resembles  a  non-virtual  enterprise,  a  single  corporation. 

In  other  words,  most  other  work  in  the  manufacturing  enterprise  considers  the 
token  being  passed  between  entities  in  the  enterprise  being  based  on  product  in¬ 
formation.  The  metrics  project  takes  a  different  view.  Since  the  focus  is  primarily 
on  the  formation  of  the  VE,  the  product  is  the  VE  infrastructure  itself.  The  focus  is 
on  how  processes  integrate,  the  dynamics  of  which  are  somewhat  independent  of 
the  product  data  flow.  What  is  sought  are  similar  tokens  in  the  form  of  process 
metrics. 

There  is  a  similar  difference  in  paradigms  between  EC  and  the  AVE.  Commerce’s 
token  of  exchange  is  the  monetary  unit  (dollars),  and  EC  continues  that  paradigm. 

The  VE  explicitly  includes  the  customer,  but  it  is  assumed  that  the  partnership 
is  more  intimate  (potentially)  than  a  conventional  buyer/seller  one.  As  a  working 
definition,  the  VE  deals  with  integration  of  processes,  even  across  buyer/seller 
boundaries  (and  supplier-chain  boundaries).  Most  EC  efforts  reinforce  walls  at 
those  boundaries  by  making  them  operate  faster  and  cheaper. 

13.8  Product  Data,  NIIIP 

[Agility  depends  on  process  coordination  in  a  way  not  affected  by  the  benefits  of  improved  product  data  ex¬ 
change,) 

Much  work  in  the  manufacturing  enterprise  considers  the  token  being  passed 
between  entities  in  the  enterprise  as  based  on  product  information.  This  is  a  nat¬ 
ural  perspective  in  some  sectors,  especially  the  aerospace  and  automotive  indus¬ 
tries.  The  National  Industrial  Information  Infrastructure  Program  (NIIIP),  as  well  as 
^many  others  which  use  the  product  data  standard  STEP  (STandard  for  the  Ex¬ 
change  of  Product  Data),  is  based  on  this  paradigm. 
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The  metrics  project  takes  a  different  view.  Since  the  focus  is  primarily  on  the  for¬ 
mation  of  the  VE,  the  product  is  the  VE  infrastructure  itself,  not  a  device  which  can 
be  niodeled  as  a  three-dimensional  item.  The  focus  is  on  how  processes  integrate, 
the  dynamics  of  which  are  somewhat  independent  ofthe  product  data  flow.  What 
IS  sought  are  similar  tokens  in  the  form  of  process  metrics. 

This  is  to  say  that  the  focus  is  on  process  integration,  not  product  integration. 

pe  technical  issues  involved  are  much  more  difficult  and  less  amenable  to  stan¬ 
dards. 

However,  there  may  be  some  lessons  to  be  learned  from  the  product  data  para- 
digm.  Initiatiws  using  that  paradigm  have  encountered  immense  technical  difficul- 
ties  resulting  from  the  choice  of  gracefully  growing  from  an  archaic  token  type,  the 
engineering  drawing.  Instead  of  easing  adoption  as  originally  hoped,  the  product 
data  standard  is  fighting  battles  for  adoption  not  originally  anticipated.  A  lesson 
may  be  circumspectly  to  reconsider  assumptions  Implicitly  carried  over  from  lega¬ 
cy  methods.  * 

We  stated  earlier  that  engineering  agility  into  an  organization  Is  a  radical  new 

idea.  It  would  be  crippled  by  unnecessarily  carrying  over  obsolete  concepts  as  a 
legacy. 

Elsewhere,  we  argue  that  the  general  concept  of  international  standards  is  as 
much  an  impediment  to  agility  as  it  can  be,  in  cases,  a  benefit.  Consider  the  situa¬ 
tion  where  two  persons  need  to  collaborate. 

If  what  you  want  is  a  high  level  of  plug  and  play  among  persons  and  a  high  de¬ 
gree  of  refinement  in  the  process,  standards  are  useful.  For  instance,  artillery 
crews  ^e  trained  to  use  a  standard,  concise  subset  of  English  in  communicating; 
a  specific  small  glossary  is  used.  The  standard  is  in  the  token  that  is  passed. 

The  resulting  system  is  very  agile  in  the  sense  of  being  able  to  substitute  partic¬ 
ipants.  But  it  is  unagile  when  the  situation  is  highly  unpredictable.  So  Special  Op¬ 
erations  Forces  (SEALS,  Green  Berets),  for  example,  are  not  restricted  in  what  they 
can  say,  but  instead  are  trained  in  communication  skills.  The  medium  is  full-blown 
English.  When  someone  doesn’t  understand  what’s  being  said,  they  fall  back  on 
clarifying  or  defining  new  terms  on  the  fly.  Much  more  agile. 

We  know  of  an  analogy  in  the  product  data  world.  One  supplier  chain  Is  being 
built  that  specifically  eschews  STEP,  intentionally  targeting  abilities  that  adher¬ 
ence  to  STEP  makes  more  difficult  by  making  other  enterprises  less  agile. 

13.9  Enterprise  Integration 

[Conventional  integration  strategies  depend  on  stability,  not  temporal  dynamism.] 

The  Suppliers'  Working  Group  (SWG)  made  an  investment  in  studying  agility  and 
used  the  rubric  Enterprise  Integration.  By  this,  we  meant  the  information  strategies 
required  to  quickly  and  cheaply  integrate  diverse  components  into  a  functioning 
enterprise,  as  in  an  AVE.  Since  then,  the  term  Enterprise  Integration  has  been  pro¬ 
moted  to  mean  something  quite  different,  something  much  less  challenging. 


F etnury  tS,  1997 


178 


Part  2.  Agility  Issues 


Now  it  means  the  ability  to  create  an  enterprise-wide  model.  A  robust  research, 
conference  and  standards  community  has  appeared  to  support  this  work.  Desir¬ 
able  as  this  may  be,  it  still  assumes  a  central  point  of  management  and  a  static  en¬ 
terprise.  It's  not  the  problem  we  address. 

We  now  call  our  problem  that  of  model  federation. 
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14  The  Agile  Manufacturing  Research  Program 

(The  39  sponsored  agility  programs  are  related  to  the  Reference  Model.) 

Elsewhere  we  describe  the  substantia!  effort  of  the  Agile  Virtual  Enterprise  Fo¬ 
cus  Group  and  its  prirnary  product,  the  AVE  Reference  Model.  That  model  has  prov¬ 
en  to  be  quite  useful  in  a  variety  of  contexts.  Specifically,  It  supports  the  work  of 
the  metrics  as  described  here,  it  provided  a  framework  to  categorize  the  Best  Agile 
Practices  study,  a  recent  study  of  agility  attributes,  and  a  mapping  to  the  agility  en¬ 
ablers  of  the  Agility  Forum. 

We  believe  that  the  AVE  Reference  Model  cuts  things  at  the  joints;  it's  a  clean  way 
of  looking  at  the  domain.  It's  no  accident  that  things  worked  out  well,  since  from 
the  first  the  group  decided  to  have  a  consistent  focus  on  the  process.  In  particular: 

4we  stayed  true  to  a  pure  definition  of  agility,  the  ability  to  respond  well  to  unex¬ 
pected  change 

4we  looked  at  a  new  and  novel  business  function,  the  ability  to  engineer  appro¬ 
priate  levels  of  different  types  of  agility  into  an  enterprise 
4  While  keeping  that  focus  sharp,  we  deliberately  broadened  the  view  of  the 
business  model.  While  including  conventional  integrated  enterprises  and  supply 
chains,  we  also  addressed  not-yet-seen,  advanced  models  of  the  Virtual  Enter¬ 
prise.  The  model  was  intended  to  be  generic  in  this  way, 

4We  stuck  to  process  breakdowns,  where  a  process  was  activity  which  required 
resources  and  Involved  a  decision.  This  differs  from  functional  breakdowns  which 
emphasize  roles  (marketing,  manufacturing)  not  behavior. 

4We  worked  hard  to  separate  the  infrastructures,  because  we  knew  that  differ¬ 
ent  laws  would  be  at  work. 

As  a  result,  the  Reference  Model  is  a  robust  way  to  view  at  once  the  spectrum 
of  activities  In  the  AVE  which  is  presumed  to  be  the  superset  of  ail  for-profit  busi¬ 
ness  activities.  One  use  we've  put  the  Reference  Model  to  is  understanding  some 
of  the  other  sponsored  agility  projects.  There  are  a  large  number  of  these. 

Of  these  projects,  none  deal  with  the  last  lifecycle  step,  graceful  resolution  or  re¬ 
configuration.  None,  except  ours,  deals  with  the  first  step.  Opportunity  Identifica¬ 
tion.  Only  one,  the  work  of  Work  and  Technology  Institute  deals  with  the 
importance  of  Social  and  Cultural  Infrastructure.  Our  project,  and  those  of  Intelli¬ 
gent  Systems  Technology  and  Knowledge  Based  Systems  are  the  only  ones  that 
deal  with  information  infrastructure,  which  in  our  model  is  purely  the  modeling, 
abstraction  and  representation  strategy. 

We  believe  our  project  to  be  the  only  one  focused  on  A3  Agility,  the  directly  en¬ 
gineered  ability  to  adapt  well  to  unplanned  change. 


F cimury  I5,  1997 


ISO 


Part  2.  Agility  Issues 


The  following  tables  show  the  fiill  Reference  Model  and  the  subset  of  the  mod¬ 
el’s  cells  addressed  by  the  projects..) 


1.  Opportunity  ID 
2.  Partner  ID 
3.  VE  Formation 
-1 4,  VE  Operation 
5.  Reconfig/Dissolve 


Table  14-1:  Full  Model  and  the  Cells  of  Interest 


C.  Legal/Explicit 
Infrastructure 

D.  Physical  Infrastructure 

1-15, 24. 30 

2:  Partner  ID 

22 

22 

20 

20 

3:  VE  Formation 

1-15, 24, 30 

31,32 

20 

20 

1-15,24, 30 

4:  VE  Operation 

16-19,21.23, 25-29, 36-39 

16-19, 21,23, 25-29,  36-39 

31,32 

Table  14-2:  Projects  Mapped  to  Subset  of  Reference  Model 
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^Row  2:  Partner  Identification 
^Row  3:  Formation 
^Row  4:  Operation 

^Columns  C:  Legal/Explicit  Infrastructure  incorporating  legal,  business  process 
and  workflow  issues 

^Columns  D:  Physical  Infrastructure  incorporating  warehousing/logistics,  and 
equipment  and 

The  related,  sponsored  research  projects,  are: 

^1,  Agile  Infrastructure  for  Manufacturing  Systems 
42.  Agile  Manufacturing  Development  of  Castings 
^3.  Agile  Manufacturing  Decision  Support  Systems 
^4.  Chemical  Management  Information  System 

45.  Codifying  Knowledge  about  Agile  Business  Practices 

46.  Decision  Support  System  for  the  Management  of  Agile  Supply  Chains 

47.  Enabling  Next  Generation  Mechanical  Design 
^8.  Enterprise  C3I  Decision  Support  System 

^9.  Hierarchical  Enterprise  Decision  Support 

^10.  Integrated  Process  Planning/Production  System 

^11.  Large  Scale  Simulation  and  Resource  Scheduling  Based  on  Autonomous 

Agents 

^12.  Process  Tools  for  Virtual  Enterprise  Management 

^13.  Process-WEB:  Process-enabled  Planning  and  Composition  of  an  Agile  Virtual 
Enterprise 

^14.  Tierll-F  AGILE  Support  Concept 

^15.  Virtual  Enterprise  Engineering  Environment 

^16.  Activity  Based  Costing  for  Agile  Manufacturing  Control 

^17.  Agile  Web  Pilot  Program 

^18.  Labor  Infrastructure  for  High  Performance  Transformations 

i  19.  Manufacturing  Assembly  Pilot  Project 

^20.  Metrics  for  the  Agile  Virtual  Enterprise  (This  Project) 

^21 .  Migration  Strategies  for  an  Agile  Logistics  Infrastructure 
^22.  Qualification  Criteria  for  Agile  Enterprises 
^23.  Supply  Chain  Integrated  Product  and  Process  Design 
^24.  Strategic  Planning  and  Operating  Tools  for  Agile  Enterprises 
425.  Agile  Textile/Apparel  Initiative 

^26.  Fast  and  Flexible  Communication  in  the  Aerospace  Industry 
427.  Fast  and  Flexible  Communication  in  the  Automotive  Industry 
^28.  Nationwide  Electronics  Industry  Sector  Pilot 
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429.  Advanced  Collaborative  Open  Resource  Network 
^30.  Agile  Manufacturing  Information  Infrastructure 

431 .  CAMnet  Prototype  and  Wrapper  Tools 

432.  PartNet:  An  Infrastructure  for  Product  Information  Distribution  and  Elec¬ 
tronic  Commerce 

433.  Aerospace  Agile  Manufacturing  Research  Center 

434.  Machine  Tool  Agile  Manufacturing  Research  Center 

435.  Electronics  Agile  Manufacturing  Research  Center 

436.  MEREOS 

437.  National  Industrial  Information  Infrastructure  Protocols 

438.  National  Industrial  Information  Infrastructure  Protocols  Lite 

439.  Cooperative  Network  for  Dual-Use  Information  Technology 
The  projects  clump  into  the  following  cells: 

4Spanning  C,2,  C.3  and  C.4:  are  projects  1  through  15,  24  and  30 
4Spanning  C.2  and  D,2  is  project  22 

4Spanning  C.4  and  D.4  are  projects  16  through  19,  21,  23,  25  through  29  and  36 
through  39 

4Spanning  D.3  and  D.4  are  projects  31  and  32 

4(Projects  33  through  35  are  diverse  and  are  not  categorized) 

40ur  project,  number  20,  covers  Columns  C  and  D  in  rows  1 , 2  and  3. 
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15  Summary  of  the  Method 

(Given  the  above  constraints,  a  short  statement  of  the  approach  is  given.) 

We  focus  on  analyzing  processes  to  evaluate  their  agility,  their  ability  to  adapt. 
We  provide  a  method  to  do  so,  and  indicate  associated  methods  which  are  re¬ 
quired  to  support  certain  needs. 

What  goes  into  this  evaluation  are  models  of  ordinary  processes  within  an  en¬ 
terprise  or  across  partners.  What  comes  out  are  numbers  or  functions  which  indi¬ 
cate  the  time  and  cost  of  change.  Either  a  pair  of  processes  are  compared  (resulting 
in  the  time  and  cost  of  changing  from  one  to  the  other),  or  a  single  process  and  an 
agility  scope  (resulting  in  a  time  and  cost  measure  of  the  intrinsic  ability  to  change 
in  certain  ways  of  the  process). 

The  bad  news  is  that  the  metrics  can  only  be  applied  where  process  models  ex¬ 
ist.  Where  processes  are  not  modeled,  the  models  must  be  created.  Where  explicit 
models  are  difficult  to  capture,  as  in  many  important  social  interactions,  the  be¬ 
havior  must  in  some  way  be  captured. 

The  good  news  is  that  essentially  any  modeling  method  can  be  accommodated, 
so  planners  and  managers  can  incorporate  agility  considerations  in  models  and 
tools  created  for  other  purposes.  Moreover,  an  agility  analysis  only  requires  mod¬ 
els  of  a  few  key  processes  in  the  organization,  so  incomplete  existing  models  can 
be  relatively  cheaply  supplemented  in  order  to  add  agility  considerations. 

Concerning  social  and  cultural  change,  we  have  an  approach,  representing  new 
formal  methods  developed  under  our  effort,  which  can  be  used  to  characterize  suf¬ 
ficiently  explicitly  behavior  whose  causal  processes  are  unknown. 

The  process  we  follow  is  simple  at  a  high  level.  We  start  with  models,  the  col¬ 
lected  models  of  various  processes,  which  incidentally  can  be  modeled  by  diverse 
methods.  And  we  end  up  with  models;  metrics  in  the  formal  view  that  we  take  are 
parametric  models.  The  method  we  develop  is  a  transformation  of  the  input  model 
into  the  output. 

We  do  this  in  large  measure  by  constraining  the  input  model  in  three  steps.  The 
three  filters  we  use  are  intuitively  describable: 

^Constrain  to  Infrastructure  Breakdown.  Here  we  force  the  process  decomposi¬ 
tion  to  fall  into  a  standard  parsing  of  the  Virtual  Enterprise  (VE).  This  normalizes 
the  input  models  and  directs  the  focus  to  the  creation  and  change  of  infrastruc¬ 
ture,  the  core  phenomena  of  interest. 

The  work  we  have  done  in  this  effort  is  novel,  and  it  results  in  rigorous  defini¬ 
tions  of  agility.  It  coUld  have  been  done  by  others.  There  could  be  some  mild  con¬ 
troversy  here  concerning  our  focused  use  of  terms  that  others  may  use  in  more 
loose  ways. 

^Constrain  to  Communicative  Acts.  This  forces  the  representations  into  a  stan- 
^  dard  form  that  sets  up  the  next  step.  It  results  in  a  normal  form  that  directly 
relates  interaction  with  tools  by  others,  by  agent-based  approaches,  and  by 
repositories  of  cases  and  agile  processes. 

This  work  is  borrowed  wholesale  from  others  and  rests  on  well  established,  non- 
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controversial  foundations. 

^Constrain  to  Agility  Features.  This  third  filter  is  the  most  novel;  it  extracts  five 
complexity  measures  from  the  processes  that  pertain  to  agility.  It  employs  some 
novel  mathematics  in  its  most  complex  form,  as  an  Input  to  strategic  planning/ 
simulation  systems.  But  we  have  also  developed  a  simple  arithmetic  method  for 
common  situations  that  requires  no  special  skills  or  automation  support. 

This  work  in  its  complex  form  is  based  on  unique  and  proprietary  work. 
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16  Limits  of  Our  Approach 

{The  approach  has  limits.  Here  they  are.) 


16.1  Modeling  for  Utility 

|The  modeling  approach  is  geared  to  producing  the  numbers  ts  the  useful  result.  The  interim  models  are  not 
generally  useful.) 

The  approach  that  the  project  has  taken  depends  heavily  on  modeling  science; 
much  of  the  attention  has  been  oriented  toward  understanding  the  nature  of  the 
modeling  approach  and  the  resulting  parametric  model,  the  time  and  cost  metric. 
What  goes  into  the  Reference  Model  is,  by  design,  intuitive  and  simple.  What 
comes  out  of  the  model,  the  time  and  cost:  information,  is  also  by  design  very  sim- 
pie. 

Constraining  the  design  of  the  approacn  this  way  has  the  result  that  the  black 
box  of  the  features  model  Is  somewhat  complex  and  non-intuitive.  The  term  mod¬ 
eling  is  often  used  in  the  enterprise  explicitly  to  capture  and  display  processes  and/ 
or  relationships.  Often,  the  value  of  the  process  is  in  making  things  explicit  and 
displaying  the  results  so  that  relatively  non-technical  users  can  see  what  is  going 
on. 

In  other  words,  usually,  the  priority  Is  In  making  the  graphic  display  of  the  mod¬ 
el  clear,  which  takes  priority  over  the  computability  or  formal  utility  of  the  model. 
We  have  opposite  priorities:  essentially  no  effort  is  going  into  visualization  of  the 
features  at  this  point,  and  everything  Into  making  them  computable.  The  model  is 
essentially  a  black  box  so  far  as  the  user  is  concerned. 

In  part,  we  make  up  for  the  need  for  visualization  by  presuming  a  precursor 
model.  A  user  will  model  their  organization  using  techniques  that  are  already  in 
use  for  other  management  needs;  most  of  the  time,  this  will  have  already  been 
done.  The  understanding  of  the  processes  from  visualization  is  presumed  to  be 
provided  by  this  precursor  model,  since  we  believe  that  the  nature  of  agility  is  so 
different  that  it  won’t,  by  Itself,  be  apparent. 

16.2  Necessity  for  Strategic  Modeling 

(No  strategy,  no  metrics.  A  surprising  number  of  enterprises  have  no  clear  strategy.  Strategies  are  expensive.) 

The  original  intent  of  the  project  was  to  pursue  two  uses  simultaneously,  tacti¬ 
cal  and  strategic.  Strategic  users  would  evaluate  many  options  and  a  very  large 
number  of  features  to  structure  many  elements  of  the  enterprise.  For  example,  a 
prime  contractor  would  develop  a  strategy  which  accounted  for  agility,  advising  on 
the  design  of  the  supply  chain:  what  gets  bought  and  what  factors  govern. 

The  result  would  include  what  agility  features  are  of  Interest;  what  the  relative 
weighting  of  those  features  would  be,  and  the  degree  of  agility  desired  in  each  of 
^those  features. 

The  tactical  user  is  an  empowered  decisionmaker  working  later  in  the  life  cycle, 
and  implementing  the  strategy.  For  instance,  a  middle  manager  may  be  evaluating 
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which  of  several  suppliers  support  the  enterprise’s  agility  goals.  This  manager 
deals  with  a  much  simpler  case  than  the  strategic  one;  there  are  simply  fewer  vari¬ 
ables. 

But  there  is  a  more  fundamental  difference  in  that  the  tactical  manager  is  pre¬ 
sumed  to  have  the  guidance,  the  agility  requirements,  set  by  the  agility  strategy. 
It  appears  that  we  cannot  use  the  metrics  in  any  meaningful  way  tactically  without 
such  a  strategy. 

This  is  another  limit  of  the  approach,  at  least  tactically,  and  is  a  result  of  the  un¬ 
avoidable  truth  that  all  agility  is  strategic  at  root 

16.3  Second-Order  Agility 

(This  version  measures  the  ability  to  change,  not  the  ability  to  change  your  ability  to  change.  That's  for  the  fu- 
ture.| 

In  the  course  of  the  work,  we  went  back  to  many  of  our  best  practice  examples 
to  evaluate  whether  the  metrics  would  have  been  directly  useful.  We  were  sur¬ 
prised  to  find  many  cases  of  second-order  agility  which  were  not  captured  in  the 
original  approach. 

Second-order  agility  is  a  result  of  those  actions  that  do  not  directly  follow  from 
the  existing  state  of  the  enterprise.  A  second-order  effect  would  appear  if  an  early 
response  to  a  change  fundamentally  changes  the  enterprise’s  ability  to  respond. 
For  example,  consider  the  simple  case  of  physical  agility  in  equipment  and  the  sim¬ 
ple  dimension  of  increased  capability.  A  first-order  measure  would  consider  the 
ability  to  increase  the  output  of  the  existing  equipment. 

But  what  if  the  supplier  has  an  outstanding  order  for  new  equipment  which  they 
accelerate  as  a  result  of  the  new  demand.  This  is  meaningful  agility  that  Is  not  ap¬ 
parent  from  examining  the  capability  of  the  existing  physical  system  alone.  But  this 
capability,  the  ability  to  order  and  quickly  incorporate  new  equipment,  can  be  cap¬ 
tured  if  at  the  system  level. 

The  lesson  is  that  the  knowledge  that  is  captured  must  include  features  from  a 
system-wide  perspective.  Our  initial  belief  that  local  analysis  would  have  some  in¬ 
cremental  benefit  was  false;  in  order  to  get  any  appreciable  value,  the  features 
need  to  be  evaluated  system-wide. 

The  resulting  constraint  is  that  the  metrics  are  not  incrementally  implement- 
able.  In  fact,  since  the  social  and  cultural  factors  have  been  excluded  from  the  first 
phase  of  the  work,  the  interim  metrics  are  incapable  of  fully  exploiting  second-or¬ 
der  agility.  This  limit  on  the  approach  also  results  from  the  fact  that  agility  is  es¬ 
sentially  a  strategic,  system-wide  set  of  capabilities,  not  a  state. 

16.4  Possible  Lack  of  Quantitative  Information 

I  (Suppliers  will  have  scant  idea  of  the  questions  you'll  be  asking.  There  are  additional  costs  associated  with  ed¬ 
ucation,  with  obvious  side  benefits.] 
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In  future  work,  we  intend  to  develop  a  modeling  technique  to  insure  the  cor¬ 
rectness  and  completeness  of  the  knowledge  capture  process.  But,  until  then,  we 
have  to  depend  on  existing  modeling  techniques,  under  the  assumption  that  en¬ 
terprises  will  want  to  use  information  that  is  already  captured,  or  to  use  methods 
with  which  they  are  familiar. 

We  need  information  that  is  captured  in  quantitative  form,  together  with  all  of 
the  relevant  causal  relationships.  Both  characteristics,  being  quantitative  and  in¬ 
cluding  causality  are  desirable  for  the  integrity  of  the  approach.  But  we  find  that 
such  information  rarely  exists  in  cheaply  accessible  forms,  much  more  rarely  than 
we  initially  thought. 

Most  quantitative  information  suffers  from  the  accountant’s  syndrome:  effects 
are  measured,  usually  in  the  form  of  time  and  cost,  but  the  complex  causal  rela¬ 
tionships  that  a  robust  model  would  capture  are  lacking. 

Another  problem  is  the  nature  of  the  existing  models  where  some  dynamics  and 
inter-relationships  are  captured.  Models  fall  into  one  of  three  types:  descriptive, 
qualitative,  and  quantitative.  The  first  type  are  the  most  common  and  the  least  use¬ 
ful  for  our  purposes.  Usually,  they  just  display  relationships  as  an  aid  to  help  man¬ 
agers  think  more  deeply  than  they  otherwise  would. 

Our  site  visits  revealed  very  little  in  the  way  of  existing  quantitative  information, 
which  means  that  the  information  collection  process  could  be  more  expensive 
than  originally  thought.  The  good  news  is  that  the  approach  overall  is  tolerant  of 
the  type  of  input.  One  cannot  get  high  integrity  quantitative  information  out  even 
if  only  descriptive  information  is  fed  in.  But  some  coarse  analysis  can  be  done  with 
notional,  descriptive  information  so  that  one  can  determine  where  more  apt  infor¬ 
mation  gathering  is  profitable.  Therefore,  this  limit  of  the  process  is  not  so  severe. 


16.5  Agility  and  Evolution 

[Becoming  agile  may  require  a  more  serious  commitment  to  reinvention  than  most  firms  are  willing  to  make.] 

The  final  limit  on  agility  is  perhaps  the  most  basic.  The  concept  of  engineering 
agility  is  a  radical  idea  which  is  already  eminently  useful  in  many  sectors.  But  its 
radical  nature  can  be  a  disadvantage  as  well.  Agility  is  a  simple  concept  to  under¬ 
stand  in  theory,  but  conceptually  it  can  be  difficult  to  apply  to  specific  cases.  Four 
years  of  work  by  the  Agility  Forum  has  underscored  this  difficulty. 

The  actual  identification  of  agile  needs  or  behavior  in  a  specific  application  is 
the  only  major  step  that  has  thus  far  eluded  us  in  pinning  down  a  rigorous,  com¬ 
prehensive  definition.  Identifying  such  needs  appears  to  rely  on  some  art  in  the  eye 
of  the  analyst  as  well  as  some  fearlessness  in  abstraction. 

For  example,  according  to  the  way  we  describe  it,  the  whaling  industry  was  ag¬ 
ile,  with  some  of  its  core  competencies  surviving  to  the  present  day  and  forming 
the  basis  of  our  largest  contributor  to  balance  of  payments  (movie-making).  But  all 
hat  would  be  scant  comfort  to  the  by-passed  candlemaking  enterprises,  to  whom 
the  whole  affair  appeared  quite  brittle.  In  the  SEMATECH  example,  the  idea  that 
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the  manufacturing  goal  was  in  the  fab  and  not  in  the  chip  could  not  be  adhered  to 
even  after  initially  adopted  by  the  sponsoring  group. 

We  offer  the  following  insight:  some  problems  in  identifying  agility  behavior  or 
needs  boil  down  to  insecurity  about  whether  agility  is  a  tool  to  maintain  an  accus¬ 
tomed  evolution  (in  effect,  the  status  quo),  or  to  enable  a  directed  revolution. 

If  an  automobile  company  looked  at  agility  as  a  technique  merely  to  improve  its 
competitiveness  without  fundamentally  re-examining  itself  and  what  it  does,  it 
may  have  trouble  coming  to  terms  with  what  agility  is.  It  will  most  likely  see  agility 
as  much  like  other  productivity/profit  maximizing  techniques,  such  as  those  col¬ 
lected  under  the  rubric  of  lean. 

If,  on  the  other  hand,  an  industry  is  undergoing  revolution,  and  a  company  is 
looking  for  a  way  to  continually  reinvent  itself,  to  change  in  order  to  take  advan¬ 
tage  of  change,  then  agility  is  easily  applied.  The  questions  then  become  less  in¬ 
transigent,  and  the  needs  are  more  apparent.  We  believe  that  the  aerospace 
defense  community  is  unavoidably  in  such  a  revolution,  and  so  is  an  apt  candidate 
for  agility. 

The  U.  S.  automotive  industry  (including  workers,  industry  suppliers,  and  the 
follow-on  repair  market)  is  instead  in  the  mode  of  working  to  preserve  large,  stable 
institutions  and  practices  with  a  minimum  of  change,  so  will  likely  perceive  agility 
in  a  more  limited  way. 

It’s  a  question  of  whether  we  merely  react  or  we  intentionally  build  an  ability  to 
adapt.  We,  of  course,  are  promoting  the  latter.  The  underlying  issue  is  whether  the 
cost  of  much  evolutionary  change  is  actually  less  in  real  terms  than  the  cost  of  pos- 
sibly-smal!  changes  based  on  revolutionary  analysis.  Each  enterprise  must  make 
that  evaluation  for  itself  in  considering  engineering  of  agility. 
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[Part  3  is  for  the  reader  who  is  interested  in  social  and  cultural  issues  and  what  weVe  done  about  them.  Many 
examples  are  in  this  part.] 


17  Abstract 

We  begin  this  part  by  recounting  an  extensive  example  beginning  in  the  whaling 
industry  and  ending  with  agile  movie  production  processes.  We  continue  with  a 
specific  movie  case,  software  coding,  Russian  entrepreneurs,  and  virtual  car  man¬ 
ufacturing. 

Cultural  agents  are  introduced,  and  some  background  issues  discussed.  Trust, 
trust  agents  and  trust  metrics  are  defined. 

We  review  French  and  English  history  to  extract  key  insights  into  defense  engi¬ 
neering  practices.  Then  we  tie  it  back  to  the  movie  example  with  a  case  of  trusted 
agents  using  lightweight  contracts  and  unifying  themes.  And  the  whole  affair  is  fur¬ 
ther  tied  back  to  the  defense  case.  The  case  for  defense  support  is  made. 

We  then  turn  to  the  specific  approaches  to  soft  mathematics.  Situation  theory 
is  introduced  and  explained. 

We  report  on  our  activity  in  setting  up  a  workshop,  report  results  of  that  work¬ 
shop,  and  detail  future  action  that  we  plan. 
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18  An  Historic  Case 

(The  primary  focus  of  this  section  is  the  thread  of  case  studies  revolving  around  the  movie  production  business.] 

Much  of  the  principle  investigator's  career  has  been  devoted  to  helping  shape 
U.S.  Department  of  Defense  investments  for  the  domestic  industrial  fabric.  Befud¬ 
dled  by  contrasting  speculations  on  best  strategies,  he  searched  for  some  hard 
data  derived  from  similar  prior  situations.  What  he  found  surprised  him  in  terms 
both  of  the  successes  and  the  failures~and  convinced  him  that  historical  cases  can 
be  helpful  for  understanding  the  virtual  enterprise  and  the  government’s  role  in 
providing  for  them  supporting  technology. 

18.1  Military  Research  “Can”  Do's  and  Don'ts 

(Defense  research  flubbed  up  on  the  can  opener.  Why?) 

Military  research  has  influenced  daily  life  to  a  much  greater  extent  than  most  of 
us  realize.  For  example,  the  British  military  sponsored  the  development  of  the 
now-ubiquitous  tin  can  in  1810.  This  innovation  brought  to  critical  mass  forces 
which  revolutionized  agriculture,  since  food  could  be  distributed  like  a  manufac¬ 
tured  good.  The  military’s  concern  was  the  long  range  projection  of  supportable 
military  power,  and  this  one  advance  played  a  consequential  role  in  the  expansion 
of  the  British  Empire. 

What  is  surprising  is  that  the  con  opener  was  not  invented  for  nearly  another 
half-century.  It  ultimately  appeared  as  the  result  of  a  small  U.S.  Army  research 
project,  and  the  new  can  openers  played  a  role  in  the  early  days  of  the  U.S.  Civil 
War,  since  the  South  lacked  them.  In  the  intervening  years,  cans  were  presumed 
to  be  opened  by  whatever  was  handy:  knives,  chisels,  or  even  shovels  and  bayo¬ 
nets.  It  has  been  reasonably  speculated  that  during  this  fifty  years  time  more  mil¬ 
itary  casualties  resulted  from  opening  cans  than  from  combat. 

Why  did  it  take  so  long  to  invent  what  we  now  consider  such  an  obvious  device? 
It  was  not  the  lack  of  a  well-funded  military  research  effort.  In  fa(^,  substantial 
amounts  were  spent  by  the  military  on  can  research.  But  the  requirements  for  the 
cans  came  from  the  planners,  not  the  users--so  the  efforts  focused  mostly  on  the 
optimum  size  and  shape  of  cans  for  the  variety  of  logistical  packing  situations  en¬ 
countered. 

We  found  many  cases  where  even  the  most  (retrospectively)  obvious  innova¬ 
tions  eluded  the  research  establishment.  Several  lessons  here  helped  us  immense¬ 
ly;  one  of  these  was  the  confirmation  of  the  value  of  historical  study. 

18.2  Show  Me 

[The  study  begins  with  an  interest  in  legal  agreements  for  movies.] 

In  1994,  the  Agility  Forum  decided  to  review  Best  Agile  Practices  in  businesses 
^oday.  The  study  was  intended  to  move  the  vision  and  practice  of  agility  a  giant 
/step  forward.  Sirius-Beta  was  tapped  to  lead  the  virtual  enterprise  effort.  The  Agile 
Virtual  Enterprise  Focus  Group  directed  the  work,  both  in  the  agenda  and  in  some 
of  the  enterprises  to  survey. 
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In  terms  of  the  agenda,  the  Group  was  faced  with  a  conundrum:  the  only  enter¬ 
prises  we  could  survey  were  existing  ones  working  on  current  problems.  But  the 
only  way  to  test  these  for  agility  would  be  to  look  back  from  the  future  to  see  if 
they  had  responded  well  to  change.  Some  felt  we  should  have  been  sent  out  to 
look  at  historic  examples. 

The  first  industry  we  were  directed  to  look  at  was  the  movie  production  business. 
It  IS  a  living  enterprise,  which  manifests  itself  in  very  high  value,  short-lived  part¬ 
nerships,  varying  greatly  from  situation  to  situation.  It  is  a  highly  successful  indus- 
3  significant  source  of  foreign  trade,  bested  only  by  commercial 
airliners.  And  its  role  in  technology  development  is  growing. 

Duly  following  the  direction  of  the  group,  we  consulted  a  knowledgeable  insider 
and  was  exposed  to  a  remarkable  collection  of  virtual  enterprise  practices  in  movie 
production.  The  bad  news:  in  several  interesting  cases,  we  were  unable  to  over- 
come  proprietary  wraps  on  competitive  techniques,  so  the  case  was  not  reported. 
The  good  news  was  that  our  contact  possessed  some  rare  knowledge;  he  knew 
how  one  of  the  movie  industry's  best  practices  evolved. 

The  movie  business  relies  on  a  contract  tradition  that  keeps  legal  instruments 
very  lean,  relying  on  a  near-TalmudIcally  comprehensive,  but  implicit  set  of  ethical 
principles.  Underlying  that  is  a  large  body  of  case  law  governing  the  virtual  enter¬ 
prise.  Together,  they  provide  a  sufficiently  robust  adjudication  mechanism  that  the 
partnerships  can  be  made  quickly  and  cheaply.  Remember  when  Kim  Bassinger  was 
bankrupted  for  reneging  on  a  simple,  verbal  statement  that  she  would  do  a  pic¬ 
ture?  ^ 

This  case  law  and  partnering  tradition  can  easily  be  traced  to  the  early  oil  explo¬ 
ration  business,  according  to  our  enlightened  informant.  Los  Angeles  in  its  pre- 
movie  days  was  an  oil  boom  town,  and  the  movie  people  adopted  the  existing  local 
legal  infrastructure.  These  legal  practices  originated  in  the  home  of  oil  explora¬ 
tion,  Pennsylvania,  which  In  turn  inherited  them  from  the  previous  oil  industry 
namely,  the  whaling  business. 

Finally!  An  important  historical  case.  Now  we  could  test  agility  in  a  longer  time 
frame  and  simultaneously  satisfy  my  penchant  for  examples  outside  of  our  current 
buzzword  analyses.  What  we  found  greatly  expanded  our  understanding  of  how 
an  agile  virtual  enterprise  could  work. 

18.3  The  Whale  of  Fortune 

(The  U.  S.  dominates  the  important  world  whaling  industry.] 

We  discovered  that  the  use  of  whale  oil  had  profound  effects  on  our  culture.  The 
candles  made  from  it  were  much  brighter  and  relatively  smokeless  compared  to 
the  tallow  candles  which  had  been  the  standard.  This  superior  lighting  afforded 
people  a  much  wider  range  of  nocturnal  activity;  government  and  business  were 
fbetter  able  to  function  at  night;  public  performances  of  ail  sorts  could  now  be  held 
after  dark. 
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Whale  oil  also  altered  our  society’s  relationship  with  time.  The  fine  lubricating 
oil  found  in  the  head  of  the  sperm  whale  allowed  for  the  advancement  of  mass- 
produced  precision  machining.  The  pocket  watch  became  the  first  technology 
product  for  the  masses.  It  is  hard  to  overestimate  the  impact  a  scheduled  day  has 
had  on  the  way  we  structure  our  lives  and  businesses. 

As  one  would  expect,  there  was  a  great  demand  for  such  revolutionary  products, 
which  translated  into  an  enormous  amount  of  wealth  for  those  who  could  meet  it. 
With  an  economic  multiplier  effect  comparable  to  that  of  the  semiconductor  to¬ 
day,  whale  oil  enabled  the  production  of  goods  which  could  be  sold  for  a  thousand 
times  the  cost  of  collecting  the  oil  used  to  make  them. 

For  several  decades,  first  from  Nantucket  and  then  primarily  from  the  nearby 
New  England  town.  New  Bedford,  the  expeditions  were  launched  and  received 
which  supplied  90%  of  the  whale  oil  used  in  the  world.  This  tight  grip  on  such  a 
lucrative  market  meant  that  whale  oil  played  a  more  important  role  in  maintaining 
a  favorable  balance  of  trade  for  the  U.S.  than  any  other  product,  even  tobacco  or 
cotton. 

The  whales  from  which  the  oil  was  extracted  were  hunted  mainly  in  the  Pacific 
and  Indian  Oceans.  How  was  it  that  such  a  crucial  industry  stayed  almost  exclusive¬ 
ly  centered  in  two  small  towns  located  so  far  from  the  point  of  extraction? 

1 8.4  Virtual  Whaler  Dealers 

|A  whaling  party  was  a  virtual  enterprise.) 

We  found  that  geographical  and  professional  isolation  allowed  for  the  evolution 
of  a  unique  and  very  effective  system:  a  system  which  for  many  years  put  a  brand 
new,  fairly  high  risk/high  payoff,  virtual  enterprise  (VE)  in  the  water  at  the  rate  of 
one  every  two  weeks.  Here’s  how  it  operated. 

The  return  of  each  whaling  expedition  triggered  the  formation  of  another.  It 
was  considered  an  invitation  to  bad  luck  to  reuse  the  same  combination  of  part¬ 
ners,  so  during  the  six  to  nine  months  it  took  to  recondition  the  ship  for  another 
voyage,  the  owner  of  the  boat  assembled  a  new  group  of  key  players  who  would 
join  him  in  setting  up  the  basic  physical  and  social  conditions  needed  for  a  success¬ 
ful  venture. 

The  primary  partners  required  to  launch  a  voyage  consisted  of  a  ship  owner,  an 
insurer  (of  the  ship  and  cargo),  a  provisioning  financier  to  supply  the  expedition 
with  food  and  other  consumables,  a  captain,  and  often  a  manufacturer  who  agreed 
to  buy  the  oil  at  a  set  price.  This  component  of  the  partnership  was  formed  in  the 
first  couple  of  months,  the  partners  being  determined  partially  by  availability. 

just  a  month  or  less  before  the  ship  was  ready  to  sail,  a  secondary  group  of  part¬ 
ners,  the  crew,  was  formed.  They  shared  a  distinct  cultural  background;  almost 
none  of  them  had,  or  would  ever,  serve  in  the  Navy  or  the  Merchant  Marine.  This 
^professional  distinctiveness,  coupled  with  an  intense  geographica/  concentration, 
fostered  the  development  of  a  unique  culture  based  on  the  VE. 
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Every  voyage  included  a  team  of  skilled  craftsmen-carpenter,  blacksmith,  coo¬ 
per  (barrelmaker),  and  a  sailmaker  (often  a  boatwright,  a  rigger,  and  even  a  cook 
were  also  in  this  class)-whose  combined  expertise  allowed  the  enterprise  to  re¬ 
spond  effectively  to  a  broad  range  of  situations.  Each  of  these  professionals,  along 
with  the  tools,  supplies,  and  sometimes  apprentices  they  brought  aboard,  formed 
an  essentially  self-contained  business  which  was  integrated  into  the  enterprise  as 
a  whole.  In  these  cases,  it  was  not  just  the  person  who  signed,  but  their  business. 

From  the  shipowner  to  the  cook,  everyone  was  paid  with  a  pre-arranged  per¬ 
centage  of  the  take.  The  size  of  the  shares  varied  widely,  depending  on  what  value 
one  was  expected  to  add  to  the  venture,  and  was  negotiated  at  signing.  (Ishmael 
the  narrator  \n  Moby  Dick,  signed  up  as  a  deck  hand  for  I/300th  of  the  profit.  Ish- 
maefs  companion,  Queequeg,  who  was  almost  turned  away  by  the  shipowner  as  a 
pagan,  was  ultimately  offered  a  substantiality  larger  sum  than  his  friend  after  he 
demonstrated  remarkable  skill  with  a  harpoon.) 

As  in  the  current  movie  industry,  the  contracts  which  formalized  these  partner¬ 
ships  were  very  lightweight  (usually,  for  the  whaling  crew.  Just  a  small  chit,  often 
marked  with  the  illiterate’s  X,  containing  the  person’s  name,  occupation,  voyage 
and  share),  but  were  supported  by  a  well-developed,  culturally-based  code  of  in¬ 
terpretive  ethics.  This  code  of  ethics  was  also  reflected  in  a  large  body  of  case  law 
(managed  by  the  court  in  Boston)  as  the  whalers  sought  interpretations  for  the 
wide  variety  of  unexpected  situations  they  encountered. 

Shaped  by  precedent,  this  case  law  grew  sufficiently  robust  to  support  the  light¬ 
weight  legal  agreements  of  the  VEs  which  together  comprised  an  immense  indus¬ 
try.  This  case  law  governs  the  virtual  enterprise  today-the  same  kind  of 
infrastructure  used  by  our  contact  in  the  movie  business  to  support  speedy  but  ro¬ 
bust  lightweight  contracts. 

The  constant  reconfiguration  of  the  same  people,  from  the  same  place,  into  dif¬ 
ferent  small  groups  created  a  situation  where  everybody  knew  everybody.  Word 
quickly  passed  that  one  particular  blacksmith  was  an  incompetent  loafer,  or  that 
another  could  do  the  work  of  two  men  in  half  the  time.  An  organizing  entity  had 
access  to  a  potential  partner’s  reputation,  which  had  been  established  by  the  ob¬ 
servations  of  hundreds  of  peers  who  had  worked  closely  with  him.  This  capability- 
-a  service  that  might  be  provided  by  tomorrow’s  reinvented  unions-had  the  effect 
of  keeping  the  quality  of  the  teams  high.  The  rapid  turnover  (each  voyage  took 
about  two  to  four  years)  also  hastened  the  evolution  and  universal  adoption  of 
best  whaling  practices. 

18.5  The  Guild 

(Captains  were  the  owners  of  persistent  knowledge,  culturally  bounded.) 

The  tradition  of  learning  from  combined  experience  was  especially  apparent  in 
^the  relationship  among  captains.  They  were  the  process  planners;  they  knew  what 
had  to  be  done  and  in  what  order.  Their  combined  body  of  knowledge  was  contin¬ 
uously  expanded  and  refined  through  rigorous  professional  collaboration,  which 
was  institutionalized  by  each  in  the  form  of  the  captain’s  log. 
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It  was  a  primary  part  of  every  captain’s  job  to  take  detailed  notes  each  time  a 
whale  was  sighted  and  to  record  when  and  where  they  were  absent.  A  specialized 
shorthand  evolved;  for  instance,  they  marked,  with  specialized  stamps,  the  type 
and  approximate  size  of  the  whale.  They  wrote  down  the  direction  in  which  the 
whale  was  going,  at  what  longitude  and  latitude  it  was  seen,  at  what  time  of  day, 
the  weather,  any  notable  antecedents,  and  even  the  disposition  the  whale.  In  this 
way,  they  provided  documentation  for  significant  process  innovations  afforded  by 
a  combined  analysis  of  all  such  logs  during  the  six  to  nine  month  period  of  VE  for¬ 
mation,  a  period  of  strategic  planning. 

The  U.S.  government,  aware  that  these  efforts  were  essential  for  maintaining  an 
American  lead  in  the  whaling  industry  (and  hence  dominance  of  the  sea),  autho¬ 
rized  the  Navy  to  do  knowledge  representation  research  to  help  improve  the  quality 
of  the  captains^  logs  and  of  the  subsequent  analysis.  This  was  likely  the  first  mili¬ 
tary-industrial  joint  research  in  process  modeling  and  planning.  The  Navy  also  in¬ 
vested  in  navigation,  sea  flow,  animal  migration,  and  weather  prediction  aids, 
transferring  the  resulting  technology  to  the  captains. 

The  resulting  jargon,  tailored  for  describing  the  pertinent  details  of  the  profes¬ 
sion,  acted  as  a  form  of  security  protection,  as  only  an  insider  would  have  been 
able  to  extract  the  full  meaning  from  a  captain's  log.  The  process  plans  were  shared 
freely  among  the  captains  of  Nantucket  and  New  Bedford  but  not  with  outsiders. 
Collectively,  they  contained  data  taken  from  thousands  of  expeditions  and  were 
used  to  discern  the  migratory  patterns  of  the  desirable  whales.  With  this  Informa¬ 
tion,  the  American  captains  could  find  the  whales  at  any  time  of  the  year,  an  ability 
their  competitors  lacked. 

Realizing  that  the  captains  and  their  collected  knowledge  were  the  reason  for 
the  U.S.os  advantage  in  the  whaling  industiy,  one  entrepreneurial  British  noble¬ 
man  visited  Nantucket,  expecting  that,  having  seen  their  preferred  setting,  he 
could  then  build  an  even  more  favorable  one  in  England  and  lure  them  there.  This 
plan  failed,  only  one  of  many  unsuccessful  attempts  by  the  international  competi¬ 
tion. 


18.6  The  Gilded 

|An  agile  response  as  whalers  respond  to  the  gold  rush.) 

Agility  is  often  displayed  as  an  ability  to  recognize  and  capitalize  on  a  changing 
situation  as  an  opportunity.  A  whaling  Captain  Starbuck,  hearing  of  the  Gold  Rush 
in  California,  correctly  assumed  that  success  depended  not  on  metallurgical,  but 
on  organizational  skills,  the  same  skills  which  the  VE  routinely  exercised  in  whal¬ 
ing. 

He  led  an  expedition  which  was  typical  of  many  others.  With  the  ability  to  form 
and  transport  well  equipped,  versatile  teams  to  the  area  quickly  (some  ships  on 
^their  way  to  the  whales  heard  the  news  of  the  gold  and  diverted  en  routel)  the 
whalers  made  very  effective  miners. 
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At  first,  while  they  were  still  able  to  find  buyers,  they  sold  their  ships  for  scrap 
in  San  Francisco,  and  later  they  simply  abandoned  them  in  the  bay.  Testifying  to 
the  sound  design  of  these  VE  partnerships,  the  same  basic  team  was  used  for  min- 
ing~except  that  there  wasn’t  much  use  for  the  sailmaker.  (Levi  Strauss,  one  such 
sailmaker,  built  a  business  making  durable  pants  for  the  miners  out  of  the  aban* 
doned  canvas  and  rivets.) 

Complementing  the  suitability  of  the  whalers  as  a  unit,  the  partners  themselves 
possessed  a  constitution  well  matched  to  the  challenges  of  mining.  These  men 
were  used  to  living  the  hard  life;  family  separation,  poor  food,  and  long  hours  were 
the  norm  on  a  voyage.  They  were  accustomed  to  delaying  financial  gratification 
and  following  orders,  even  while  handling  material  of  great  value.  Apparently,  they 
could  also  limit  their  consumption  of  alcohol  well  enough  to  stay  alive  for  the  du¬ 
ration  of  the  mining  process,  a  skill  lacked  by  many  of  the  other  miners,  some  of 
whom  were  successful  in  other  regards. 

18.7  Oils  Well  That  Ends  Whale 

lAnother  agile  response  as  the  whole  industry  reinvents  itself.) 

Fortunately,  for  those  interested  in  a  case  of  agile  response  to  economic  disaster, 
the  first  oil  well  was  drilled  in  Titusville,  Pa.  in  1859,  right  at  the  height  of  the  whal¬ 
ing  industry’s  golden  age.  Petroleum,  available  in  great  quantities,  quickly  became 
cheaper  to  produce  than  whale  oil,  and  could  be  used  to  manufacture  similar 
things.  Each  new  rig  in  effect  represented  a  broadside  to  the  whaling  industry. 
During  the  worst  period,  demand  for  whale  oil  fell  about  15%  a  year  for  7  years. 

The  whalers  responded  by  drawing  up  new  process  plans  and  retooling-with 
the  help  of  the  Navy~in  order  to  shift  away  from  hunting  sperm  whales  in  the  Trop¬ 
ics;  they  moved  to  the  Arctic  to  hunt  baleen  whales,  whose  long  flexible  teeth  (ba¬ 
leen)  could  be  sold  to  manufacturers  of  corsets,  buggy  coaches,  and  umbrellas.  The 
industry  stayed  strong  for  another  thirty  years,  the  whalers  having  effectively  dou¬ 
bled  the  life-span  of  the  most  prosperous  years  of  their  trade. 

18.8  Some  Lessons  Learned 

(Culture  is  key.  In  this  case,  it  lead  to  trust-enabling  case  law.  The  culture  may  have  a  self-preserving  life  of  its 
own.) 

The  whole  experience  described  above  taught  some  lessons  about  the  AVE.  The 
Metric  project  assumes  that  the  AVE  can  be  engineered.  What  we  have  seen  in 
this  historical  research  is  an  AVE-enabling  environment,  or  several  of  them.  So  it  is 
reasonable  to  conclude  that  some  features  which  were  important  in  this  example 
would  also  be  desirable  to  engineer  into  an  enterprise. 

Initially,  the  whaling  industry  depended  on  a  unique,  homogenous  culture,  iso¬ 
lated  geographically  (on  an  island,  Nantucket,  before  it  included  the  deeper  port 
>of  New  Bedford),  religiously  (Quaker),  and  professionally  (not  mixing  with  other 
marine  cultures).  But  over  the  life  of  the  example,  many  decades,  this  culture,  with- 
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out  adaptations,  likely  would  have  stagnated.  One  historian  speculates  that  several 
challenges  to  the  culture  were  instrumental  in  keeping  it  strong. 

When  the  center  of  the  oil  industry  moved  to  the  mainland,  it  became  separated 
from  its  Quaker  heritage.  Quite  interesting  is  the  subsequent  assimilation  of  peo¬ 
ple  from  different  national  and  ethnic  cultures.  Over  time,  the  community  became 
quite  diverse,  as  other  nationalities  and  natives  from  prirnitive  locations,  many 
from  the  South  Pacific,  and  some  from  Africa,  were  assimilated.  This  seemed  to 
prompt  a  reinforcing  evolution  of  the  culture.  Was  it  an  accident  that  it  Was  the 
custom  to  change  crews  each  voyage?  Perhaps  it  was  an  instinctual  move? 

Much  has  been  made  of  trust  in  agility  discussions.  The  whaling  example  used 
a  very  lightweight  contractual  infrastructure.  Clearly  this  was  based  on  trust,  but 
much  of  that  trust  seems  to  have  been  based  on  a  confidence  that  the  law  would 
apply  just  principles  to  arbitrate  in  unknown  situations.  It  appears  that  this  by  it¬ 
self  constituted  a  significant  barrier  to  entry  into  the  business  by  countries  whose 
law  was  based  on  code. 

The  comparative  cases  of  privateers  (sanctioned  pirates)  among  French,  Spanish 
and  English  opportunists  clearly  shows  the  value  of  common  law  (or  case  law)  as  a 
foundation  for  trust  in  the  ships.  In  both  the  English  privateer  and  the  U.  S.  whaling 
situations,  a  simple  system  of  shares  was  made  possible.  Systems  based  on  code 
law  were  fragile,  since  the  conditions  of  such  adventures  were  so  unpredirtable. 
Cheating  and  mistrust,  and  a  subsequent  lack  of  robust  recourse  in  the  justice  sys¬ 
tem,  were  more  prevalent  among  the  privateers  from  countries  with  code  law. 

This  common  (or  case)  law  basis  of  trust  carries  over  today  in  the  filrn  industry, 
where  agents  inside  the  culture  form  share-based  VEs  predicated  on  ethics  that  are 
attuned  to  a  (still  developing)  case  law.  It  appears  to  be  no  accident  that  the  cen¬ 
ters  of  film  activity  in  terms  of  quantity  and  diversity  are  all  former  British  colonies- 
-Indla,  Hong  Kong,  and,  of  course,  the  U.  S.  French  film  industry  executives  often 
complain  of  a  structural  difference  that  stifles  them,  a  stifling  which  is  actually  ex¬ 
acerbated  by  government  subsidy  (and,  in  this  case,  the  greater  the  subsidy,  the 
more  stifling).  For  a  more  developed  discussion  on  this  issue,  see  A  Key  Difference: 
The  Engineering  Paradigm  below. 

It  is  notable  that,  despite  substantial  wealth  and  ener^,  the  whaling  industry 
never  became  vertically  integrated  up  the  food  chain  to  include  the  manufacture 
of  products.  This  lack  of  tight  linkage  allowed  agility  in  changing  the  food  chain 
from  oil  to  baleen.  And  it  also  provided  agility  in  allowing  those  manufacturers  to 
switch  to  petroleum  as  soon  as  the  opportunity  appeared. 

The  linkage  up  the  precision  machining  chain  was  also  very  loose.  The  U.  S.  dur¬ 
ing  this  period  was  never  able  to  catch  the  Germans  and  Swiss,  whose  innovation 
was  highly  dependent  on  sperm  whale  oil  lubrication.  (Incidentally,  that  oil  contin¬ 
ued  to  be  used  until  the  1970s  for  applications  of  the  most  demanding  precision, 
like  gyroscopes  on  the  Apollo  mission,  and  similar  military  missiles,  until  being  re- 
Jplaced  by  the  oil  from  the  jojoba  bean.)  So  it  seems  that  a  loose  supply  chain  cou- 
'  pling  Is  often  more  agile,  which  is  contrary  to  current  lean  thinking. 
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Finally,  we  looked  closely  at  the  government  (mostly  Navy)  support  of  the  indus¬ 
try.  Evidently  what  was  most  useful  was  infrastructure  research  on  navigation, 
record-keeping,  map  making,  and  on  specific  high-tech  tools  like  telescope  optics. 
Government  research  apparently  failed  in  all  the  direct  tools,  like  improved  ship, 
boat,  harpoon,  and  storage  container  designs.  In  each  case,  the  market  responded 
faster  and  better  with  new  solutions.  These  bubbled  up  from  the  users,  and  the 
then-growing  patent  system  provided  meaningful  incentives.  It  is  worth  noting 
that  the  deliberate  exclusion  of  patent  coverage  for  infrastructure  elements  con¬ 
tributed  to  the  concurrent  lack  of  market  incentive. 

Following  the  chain  of  whaling  to  petroleum  to  movies  across  the  country  could 
lead  one  to  all  sorts  of  unsupportable  speculations.  A  smart  observer  of  social  is¬ 
sues  has  suggested  a  limit  which  she  thinks  has  been  shown  in  the  stability  of  whal¬ 
ing’s  social/cultural  system.  She  believes,  as  we  probably  all  do,  that  there  is  a  limit 
to  the  amount  of  change  a  social  system  can  accommodate.  But  she  goes  further 
in  characterizing  the  limit  as  not  one  of  breakdown,  but  one  where  power  tends 
to  be  collected  in  a  few  entities. 

The  effect  is  that  social  coherence  is  maintained  by  the  concentration  of  power 
over  the  interactions  in  the  enterprise.  It  is  as  if  the  system  surrounding  the  enter¬ 
prise  is  able  to  evolve  in  ways  apparently  harmful  to  society  in  order  to  survive. 
This  view  of  organizational  evolution  provides  another  paradigm. 

The  example  in  the  whaling  case  comes  from  what  actually  happened  when  the 
system  was  stressed  in  transitioning  to  petroleum.  When  he  first  encountered  the 
oil  business,  J.  D.  Rockefeller  was  a  clerk,  a  man  with  no  recognized  direct  business 
value  to  add.  What  he  apparently  did  add  was  a  strong  autocratic  control  paradigm 
that  acted,  ultimately,  as  an  attractor  for  immense  wealth. 

The  system  needed  this  to  survive,  since  the  various  social  balances  which  had 
evolved  over  time  were  inadequate  for  the  magnitude  of  change  being  experi¬ 
enced.  So  the  system  in  effect  chose  Rockefeller’s  autocracy  as  a  survival  strategy. 
(A  similar  analysis,  she  suggests,  could  apply  to  the  software  industry.) 

We’ll  return  to  many  of  these  issues  in  this  Part  3  on  soft  modeling  of  social/cul¬ 
tural  issues  in  the  AVE. 
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19  Social  Issues  at  Work 

(More  examples.] 

We’ve  had  to  separate  out  the  Social/Cultural  infrastructure  from  our  initial 
project  scope  because  rigorous  modeling  techniques  don’t  exist.  But  everywhere 

wiX  setIJely  ifmfredin  applTcthnir  ** 

Consider  the  following  examples: 

19.1  Waterworld 

(One  Japanese-owned  studio  makes  a  bad  cultural  decision.) 

tie^from  mnvtJ  ^7“^'  Enterprise  (AVE)  dynamics  and  possibill- 

all  on  floating  sets.  Two  of  these  sets  were  to  be  constructed  from  scratch,  as  is^ 
than  for  mosr  ^o'^^ver,  there  was  a  longer  development  period  for  this  film 

f^ced  with  two  choices  in  assembling  its  Virtual 
erprise  (VE)  to  supply  these  sets.  The  default  choice  Involved  using  the  existing 
pool  of  craftsmen  who  already  were  a  normal  part  of  the  industiy.  These  people^ 
understand  the  foibles  and  peculiarities  of  the  business.  ^ 

r.lT  ‘^o'lvey  a  feel  and  also  to  accommodate  the  mechanics  of 

camera  placement  and  movement.  In  both  cases,  frequent  changes  to  the  sets  are 
communicated  verbally  through  the  day  In  language  which  would  often  be  unintel¬ 
ligible  to  outsiders,  and  some  of  the  changes  would  be  effeaed  overnight.  This 

way  of  working  among  designers,  engineers,  and  craftspeople  is  unique  to  the  in¬ 
dustiy,  in  the  dominance  of  artistic  effect.  iwuciomein 

H  Ji  backed  the  engineering  and  safety  skills  necessary  to 

deal  with  floating  sets.  To  provide  those  skills  would  have  required  sending  people 

nf  Hv  alternative  was  to  go  outside 

community  (who  shared  the  culture)  to  a  company  which  under- 
Stood  the  engineering  and  safety  issues  involved. 

They  had  a  firm  anticipated  cost  to  use  the  existing  craftsmen.  To  this,  thev 
needed  to  add  about  $3  million  for  engineers’  schooling,  safety  training,  and  addi¬ 
tional  insurance.  The  Japanese  conglomerate  which  owned  the  studio  vetoed  this 
use?  expensive  and  directed  that  an  outside  group  of  marine  experts  be 

So  a  contract  went  out  to  a  well-known  shipbuilding/aerospace  concern  to  en- 

company  follows  a  model,  conventional  In  their 
mdustty,  where  all  the  requirements  are  set,  then  the  design  and  engineering  per- 
^formed,  and  finally  the  items  manufactured  and  supported.  Needless  to  sav  there 
'was  a  substantial  distance  between  the  cultures  of  the  engineeTwpbuiWer  and 
tl^e  rest  of  the  produaion  s  AVE.  Artistic  effect  is  an  alien  concept  and  all  commu- 
nication  is  explicitly  engineering-based. 
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This  cultural  distance  became  an  important  factor.  The  VE  presumed  ad  hoc  flex¬ 
ible  responses,  based  on  an  implicit  group  vision  of  artistic  intent.  The  partner 
worked  on  a  very  rigid,  sequential  set  of  non-artistic  processes,  each  one  of  which 
needed  explicit  documentation. 

Production  costs  skyrocketed  as  many  small  events  slowed  down  the  process 
and  compromised  the  artistic  value  of  the  end  result.  One  such  notable  event  was 
the  accidental  sinking  of  one  of  the  sets!  The  estimated  additional  cost,  over  the 
original  cost  of  construction,  was  about  $80  million.  As  it  happens,  that  is  the 

amount  that  the  Japanese  management  was  forced  to  eat  when  unloading  the  pro¬ 
duction  company. 

We  were  reliably  told  that  a  metric  which  measures  the  cost  of  social  differences 
certainly  would  have  been  of  paramount  utility  in  this  case.  Even  if  based  on  the 
roughest  of  approximations,  it  could  have  warned  of  the  more  than  an  order  of 
magnitude  in  cost  difference. 

19.2  Indian  Software  Collectives 

IHomogeneous  culture  is  key  to  fast  software  in  India.) 

application  with  which  many  of  us  contend:  software  development 
We  ve  been  dealing  with  a  large  company  which  develops  software  as  a  product. 
Often,  firms  such  as  this  have  to  choose  between  make-or-buy,  and  one  of  their 
buy  options  has  become  quite  interesting. 

relatively  new  phenomenon  of  Indian  software  collectives 
What  happens  here  is  that  a  professor,  usually  in  what  we  would  call  a  junior  col- 
lege,  trains  a  significant  number  of  students  in  the  rudiments  of  being  program¬ 
mers.  Then  these  trainees  are  set  up  in  their  homes  with  modest  PCs  and  are 
marketed  to  the  West  by  the  professor  or  a  colleague. 

The  main  value  of  these  collectives  is  not  that  the  hourly  wage  is  cheap  com¬ 
pared  to  the  West,  though  that  is  the  case.  What  matters  most  is  that  these  collec- 
pves  can  produce  relatively  bug-free  software  in  half  or  a  third  of  the  time  of  their 
U.  S.  counterparts.  The  reason  is  strength  through  selective  ignorance. 

In  the  West,  a  typical  software  development  team  is  composed  of  creative  indi¬ 
viduals  who  have  been  exposed  to  many  philosophies  and  controversies.  It  is  very 
hanj  to  decompose  a  problem  and  get  everyone  working  to  exactly  the  same  script 
and  to  use  the  same  procedures  to  resolve  interface  and  common  service  issues 
The  most  desired  software  coders  are  the  brightest,  but  each  of  these  has  their 
own  Ideas  that  slightly  color  their  implementations.  These  slight  differences  are 
the  cause  of  both  the  most  numerous  and  the  most  vexing  bugs. 

In  rural  India,  on  the  other  hand,  each  of  the  programmers  has  been  exposed 
only  to  the  professor’s  limited  views.  He  or  she  decomposes  the  problem,  and 
that  s  that.  No  controversies  are  raised  because  no  one  knows  any  other  way  and 
^because  questioning  the  professor  is  culturally  unacceptable.  The  resulting  soft- 
ware  therefore  does  not  represent  the  most  sophisticated  approach,  but  it  has  the 
desirable  quality  of  working  seamlessly  and  being  delivered  much  faster  to  market. 
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Software  buyers  in  the  U.  S.  are  tempted  in  their  evaluations  of  the  potential  use 
of  these  teams.  On  the  surface,  they  appear  to  win  hands  down.  But  there  are  sub¬ 
tle  questions  of  mapping  the  cultural  needs  of  the  customer  to  the  cultural  ap¬ 
proach  taken  by  the  programmers.  Not  the  least  of  these  is  the  ability  to  anticipate 
ftiture  improvements  and  maintenance.  That’s  most  often  the  reason  for  the  U.  S. 
programmers’  small  differences  with  each  other. 

Subtle  user-philosophy  issues  come  into  play  as  well,  and  sometimes  they  make 
the  difference  in  customer  satisfaction.  There’s  an  art  to  this,  and  a  reading  of  cus¬ 
tomer  desires,  that  often  is  lost  in  crossing  cultures. 

We’ve  been  asked  if  future  AVE  metrics  which  cover  cultural  and  social  issues 
would  be  able  to  measure  cultural  distances  among  the  customers,  the  software 
publishers,  and  the  gaggle  of  coders.  We  think  they  might. 
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20  Role  of  Culture  as  an  Agent 

lAgility  agents,  especially  organizers,  act  in  a  social  medium.] 

We  believe  that  introducing  the  idea  of  social  factors  as  an  agent  can  be  helpful 
for  characterizing  social  effects  on  agility. 

For  example,  one  of  the  best  places  in  the  world  today  for  AVEs  is  Russia.  Many, 
many  small  businesses  are  starting  as  the  economy  converts  to  free  market  capi¬ 
talism.  A  large  number  of  these  are  aggregating  into  Type  1 ,  opportunity-driven 
AVEs,  and  some  of  the  component  companies  are  being  created  in  order  to  fill  a 
role  in  a  VE.  The  organizer  in  many  of  these  cases  is  the  Russian  mafia. 

In  this  situation,  a  decidedly  cultural  agent  plays  a  real  role,  that  ofVE  organizer. 
But  many  of  the  forces  at  work  are  conventionally  cultural.  The  mafia  certifies  part¬ 
ners  and  enforces  an  ethical  law,  and  the  mechanism  for  this  enforcement  is  less  a 
result  of  violence  (though  that  happens),  but  because  this  is  how  people  assume 
the  process  will  work. 

20.1  The  Russian  Mafia 

[Some  Russian  enterprises  are  agile  for  surprising  reasons.] 

When  the  Suppliers’  Working  Group  studied  the  most  successful  VEs,  world¬ 
wide,  it  was  struck  by  the  efficiency  of  some  large,  then-Soviet,  enterprises,  partic¬ 
ularly  in  the  aerospace  sector.  For  example,  the  Energia  Very  Heavy  Launch  Vehicle 
accomplished  its  goals  in  less  than  a  third  the  time  and  at  half  cost  of  such  a  NASA 
project  in  the  U.  S.  This  was  without  a  profit  motive,  a  national  emergency,  or  ad¬ 
vanced  information  infrastructure.  It  appears  that  something  very  much  like  the 
mafia  effect  was  at  work. 

Analysis  by  Russian  social  scientists  traces  this  effect  to  the  early  days  of  the  nu¬ 
clear  arms  race.  The  Soviet  nuclear  scientists  were  in  fact  under  a  real  threat  of 
death  upon  failure,  and  often  outperformed  their  U.  S.  counterparts,  even  adjust¬ 
ing  for  espionage. 

Clearly,  not  all  the  lessons  come  in  terms  of  direct  transferability  of  a  particular 
culture,  because  we  cannot  introduce  the  threat  of  death  into  the  risk/reward 
structure  of  the  AVE.  But  there  is  a  lesson  here  in  the  potential  utility  of  a  culture- 
based  agent. 

Our  case  law-based  movie  example  shows  the  utility  of  an  agent.  Virtually  every¬ 
one  has  an  agent  in  the  movie  business.  The  primary  benefit  of  having  an  agent  is 
not  to  handle  logistics,  as  might  be  supposed.  The  agent  is  trusted  with  negotiat¬ 
ing  and  forming  the  lightweight  no-contract  contracts  we  cite.  The  penalty  for  be¬ 
traying  trust  is  ostracism.  Both  trust  and  ostracism  are  social  mechanisms. 

The  same  dynamic  is  seen  in  a  midwest-based  Type  4  AVE,  a  bidding  collective. 
There  are  essentially  no  external  agents  involved:  the  CEOs  of  these  small  compa- 
^nies  speak  for  themselves.  But  the  same  trust/ostracism  social  mechanism  is  in¬ 
volved.  Here,  the  companies  are  geographically  proximate.  But  more  important  is 
a  long  agrarian  tradition  of  community  by  shared  trust.  Being  expelled  is  not  just 
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a  business  action,  but  one  that  affects  standing  in  the  community.  That  same  com¬ 
munity  establishes  the  fabric  of  ethics  that  governs  the  AVE. 

The  agent  is  the  rural  community  itself,  which  shares  many  features  of  the  Rus¬ 
sian  mafia. 

Finally,  the  community  as  agent  can  even  be  seen  in  the  Indian  software  collec¬ 
tive.  Here,  there  is  the  play  of  a  strong  class/caste  system,  and  the  membership  in 
a  higher  rung  of  the  middle  class  for  coders.  The  price  is  in  reinforcing  the  impor¬ 
tance  of  the  academic  culture  (and  the  role  of  the  professor)  as  the  organizing 
agent. 

Social  historians  believe  this  same  artificial  elevation  of  the  professor  as  an  or¬ 
ganizing  agent  for  industry  was  a  key  factor  in  Germany’s  early  industrial  progress. 

20.2  An  Automotive  VE 

[An  interesting  proposal  for  a  virtual  auto  plant  in  the  U.  S.,  now  in  China.] 

An  example  of  the  consequences  of  a  cultural  agent  can  be  seen  closer  to  home. 
Several  years  ago,  Sirius-Beta  participated  in  planning  for  a  massive  VE  in  the  au¬ 
tomotive  industry.  The  idea  was  to  take  advantage  of  all  of  the  manufacturing  pro¬ 
cesses  for  cars,  eliminating  the  processes  for  which  a  large  central  firm  were 
required. 

The  idea  was  to  continue  to  remanufacture  cars  after  they  were  sold.  This  idea 
extends  the  VE  both  well  into  the  customer  base  and  past  the  initial  sale.  In  one 
mode,  the  conventional  car  company  involved  would  sell  a  car  with  an  additional 
warranty:  that  car  would  have  new  technology  and  engineering  changes  inserted 
for  a  specific  number  ofyears,  in  addition  to  both  functional  and  cosmetic  repairs. 
This  would  greatly  increase  the  value  of  the  car  to  the  buyer  and  incidentally  pro¬ 
vide  a  robust,  continuing  after-sale  market  to  the  car  manufacturer. 

This  Japanese  manufacturer  knew  that  great  gains  in  conventional  market  share 
were  unlikely  and  that  they  had  already  moved  up  the  value  scale  to  luxury  cars  as 
much  as  they  could.  But  this  firm-typical  of  several-continued  to  engineer  autos 
after  the  first  manufacture,  so  that  the  later  models  differ  from  earlier  ones  to  a 
much  greater  extent  than  U.  S.  and  German  models.  In  the  latter  companies,  the 
engineering  peaks  right  before  manufacture,  and  then  stops,  unless  some  safety 
issue  is  uncovered. 

So  why  not  continue  to  re-engineer  the  model  for  years  after  the  sale?  After  all, 
quite  a  few  benefits  result,  one  of  them  being  the  extended  leverage  that  could  be 
obtained  from  the  engineering  data  and  designs  for  the  model. 

The  second  operating  mode  for  the  potential  VE  was  to  remanufacture  autos 
originally  manufactured  and  sold  by  others,  but  which  had  a  major  engineering 
flaw.  The  numbers  on  this  are  impressive.  It  turns  out  that  most  cars  are  taken  off 
the  road  not  for  systemic,  auto-wide  failure-everything  wearing  out  at  once-but 
because  of  point  failure  in  a  single  system. 

In  other  words,  the  transmission  was  poorly  designed  and  fails  again  and  again, 
so  the  car  is  Junked.  Or  a  car  Is  damaged  in  an  accident  and  not  repaired  because 


Fttruary  15,  1997 


203 


Part  3,  Soft  Modeling 


the  transmission  has  had  chronic  problems.  The  VE  would  focus  on  the  bad  actors- 
-and  models  were  drawn  up  for  many  such  cases--cars  with  good  systems  overall, 
but  which  had  one  point  failure,  a  poorly  engineered  subsystem  or  component. 

The  VE’s  job  would  be  to  design  a  newly-engineered  replacement  component, 
and  either  upgrade  a  car  retail  (with  the  owner  bringing  it  in)  or  wholesale  (with 
the  purchase  of  large  numbers  of  the  cars  from  Junl^^ards  or  used  car  dealers). 

The  VE  would  link  small  engineering,  manufacturing,  and  installation  shops  to 
do  the  work  in  a  highly  distributed  way,  along  with  central  agents-the  broker,  the 
original  engineering  base,  a  telecommunications  infrastructure  supplier,  and  a  fi¬ 
nancial  agent  which  provided  insurance  to  the  VE  and  insurance  and  funding  to  the 
small  partners. 

Anyone  could  engineer  a  new  part,  whether  working  alone  or  taking  advantage 
of  the  manufacturer’s  database.  Such  a  part  could  be  manufactured  by  the  original 
designer,  or  the  design  could  be  advertised  for  licensed  manufacture  by  others. 
Yet  a  third  party  could  be  involved  for  the  actual  installation. 

We  represented  the  government  in  this  instance;  among  the  reasons  for  doing 
so  was  the  massive  recovery  of  value  in  previously  junked  cars  to  the  U.  S.  citizen. 
The  potential  was  for  hundreds  of  millions  a  year,  the  best  kind  of  virtual  tax  cut. 
The  infrastructure  used  for  this  VE  could  be  reused,  expanded  into  other  sectors. 

Obviously,  this  did  not  proceed,  even  though  the  partners  were  available,  the 
money,  the  numbers,  and  the  technology.  What  killed  it  was  the  intimidating  so¬ 
cial  role  that  the  organizing  agent  would  have  had  to  play.  Cars  play  a  large  cultural 
role  in  American  society,  helping  people  define  their  identity.  This  dynamic  is  less 
pervasive  than  it  was  before  the  invasion  of  foreign  manufacturers,  but  many 
Americans  still  seem  to  want  a  big  company  to  which  they  can  give  their  allegiance. 

Moreover,  a  critical  mass  of  the  small  innovators  would  have  been  drawn  from 
a  pool  of  shade-tree  mechanics.  The  cultural  issues  associated  with  bringing  these 
people  together  were  considered  formidable,  especially  so  considering  the  loca¬ 
tion  of  the  test  case,  a  rural  state.  The  Japanese  decided  that  there  was  no  way  to 
manage  the  cultural  issues;  in  other  words,  appropriate  cultural  metrics  (including 
those  for  agility)  were  again  lacking. 

The  impetus  for  distributed  auto  manufacturing  shifted  to  China.  The  idea  of  re¬ 
use  has  been  shelved,  but  the  idea  of  manufacturing  cars  without  a  conventional 
prime  has  been  retained.  This  VE  is  now  to  consist  of  a  large  number  of  small  shops 
in  China,  feeding  distributed,  small,  decentralized  parallel  assembly  of  autos  for 
export. 

The  coordinating  agent  in  this  case  is  the  Chinese  People’s  Army,  which  In  fact 
is  the  largest  commercial  entity  in  the  country,  perhaps  the  world.  They  provide 
significantly  more  value  than  the  Russian  mafia,  but  the  idea  of  a  culturally-based 
agent  is  still  there. 

►  The  Japanese  are  to  provide  infrastructure  and  VE  management  techniques.  The 
cultural  situation  is  addressed  in  two  ways.  The  previous  heterogeneity  problem 
of  the  U.  S.  study  is  erased  by  going  to  China,  and  by  selecting  locations  there  with 
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deep  homogeneity.  The  arbitration  and  arranging  agent’s  cultural  skills  are  greatly 
simplified  since  the  techniques  used  will  include  the  same  as  those  of  the  Soviet 
Mafia,  namely  coercion. 

20.3  Defining  the  Culture 

(Influencing  the  culture  can  incubate  agents.] 

The  ideal  agent  will  not  only  understand  the  cultural  issues,  being  able  to  make 
informed  decisions  through  metrics,  but  it  may  be  able  to  determine  certain  cul- 
tura I  characteristics.  Whether  particular  instances  of  such  action  are  desirable  is 
another  issue.  For  instance,  it  may  be  desirable  to  have  the  Russian  mafia  in  order 
to  ease  the  formation  of  AVEs,  but  they  are  undesirable  socially  for  other  reasons. 

It  has  long  been  the  case  that  non-virtual  enterprises  have  engineered  their  cul¬ 
ture.  For  instance.  General  Electric  has  for  decades  spent  large  sums  on  under¬ 
standing  itself,  designing  where  it  wants  to  be  culturally,  and  normalizing  all  its 
employees. 

This  normalization  often  extends  to  the  customer  base.  We  mentioned  automo¬ 
bile  manufacturer  loyalty  above.  The  car  companies  spend  substantial  amounts  on 
auto  racing,  with  the  intent  of  attracting  the  kind  of  blind  (or  at  least  largely  inde¬ 
pendent  of  product  issues)  loyalty  that  is  given  to  sports  teams.  The  idea  is  to  de¬ 
termine  by  design  some  of  the  cultural  behavior  of  the  consumer. 

Probably  none  have  explored  this  territory  as  thoroughly  as  the  cigarette  com¬ 
panies.  Some  companies  have  aggressive  programs  to  adjust  the  culture  of  the 
consumer,  for  example  with  Virginia  Slims,  marketed  to  young  women.  The  Sup¬ 
pliers  Working  Group  concluded  that  these  companies  had  the  most  developed 
models  of  cultural  influence  we  could  find. 
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21  Some  Necessary  Considerations 

ISotne  charaaeristics  of  agile-producing  culture.) 

Everywhere  we  go,  we  hear  the  same  thing:  if  the  AVE  metrics  cannot  handle  so¬ 
cial  and  cultural  issues,  they  are  severely  limited.  So  the  project  developed  a  two- 
track  strategy:  deliver  fieldable  metrics  which  handle  the  explicit  (that  is  non-cul- 
tural)  issues  and  at  the  same  time  lay  the  groundwork  for  meaningful  social/cultur¬ 
al  issues  which  can  use  the  same  basic  methodology.  Along  the  way,  weVe 
discovered  some  constraining  requirements  which  are  outlined  briefly  below. 

21.1  Diversity 

(The  strongest  partnerships  are  those  among  wholly  different  partners.) 

A  common  strategy  in  forming  VEs  is  to  prequalify  partners,  using  certain  crite¬ 
ria.  Among  these  are: 

^Does  the  partner  share  our  business  vision? 

^Does  the  partner  use  business  processes  that  are  similar  to  ours? 

^Does  the  partner  share  our  interest  in,  methods  for,  and  goals  to  measure 

delighting  the  customer? 

All  of  these  are  various  ways  of  asking  if  the  partner  shares  our  cultural  values. 
We  feel  that  these,  when  taken  as  limits,  result  in  uninteresting  VEs.  The  most  in¬ 
teresting  VEs,  the  ones  that  provide  the  most  competitive  advantage,  are  those 
which  partner  you  with  someone  who  is  quite  different  and  who  offers  something 
the  VE  needs.  The  more  like  you  the  partner  is,  the  less  likely  it  will  complement 
your  capabilities  in  a  profound  way,  in  a  way  that  will  outwit  your  competition. 

It’s  not  at  all  necessary  that  your  partner  think  like  you,  or  even  that  it  gives  two 
hoots  about  your  customer,  so  long  as  there  is  real  and  true  competitive  advantage 
there  and  you  can  work  with  it  in  ways  that  are  important.  This  places  an  extraor¬ 
dinary  burden  on  the  cultural  metric.  It  cannot  look  merely  at  cultural  closeness.  It 
has  to  look  at  cultural  aptness. 

Diversity  certainly  Is  a  virtue  in  the  AVE  world;  we’ll  be  counting  on  the  metrics 
to  tell  us  what  kind  and  how  much. 

21.2  Importance  of  Language  (and  Unimportance  of  Standards) 

(Because  diversity  is  key,  simple  standards  may  be  bad.  Better  to  have  a  cheap  way  of  developing  adaptive  in- 
terfaces  on  the  fly.| 

The  same  argument  goes  for  standards  and  even  for  languages.  In  the  case  of 
standards,  the  common  approach  is  to  insist  that  the  partner  or  supplier  use  the 
same  set  of  standards  that  you  do.  Thus,  you  might  require  that  a  partner  use  a 
three-dimensional  product  model  that  is  compatible  with  or  generated  by  the 
same  vendor’s  system  as  yours.  That  certainly  makes  life  easier,  and  a  major  stan- 
'dards  effort  (STEP,  the  International  STandard  for  the  Exchange  of  Product  Data)  Is 
based  on  this  premise. 
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But  already  there  are  primes  in  the  Israeli  defense  community  that  seek  out  sec¬ 
ond-tier  engineering  shops  which  use  specialized,  deliberately  non-STEP-compli- 
ant  CAD  tools.  This  is  because  these  tools  offer  specific  power  that  mainstream 
tools  do  not,  and  the  special  power  compliments  that  of  the  prime.  They  worry 
about  how  to  send  STEP  data  to  their  customer  some  other  way  than  getting  it  in 

that  form  originally. 

Standards  can  be  useful  to  an  extent,  in  making  it  possible  for  partners  to  plug- 
and-play,  when  that  will  suffice,  but  universal  standards,  the  standards  which  go 
through  the  official  standards  process,  often  constrain  diversity.  That  diversity  of¬ 
ten  reflects  a  cultural  basis  that  is  useful  to  the  VE.  We  believe  that  conventions 
are  needed,  but  truly  agile  systems  will  adapt  special  conventions  only  where  they 

are  beneficial. 

Similarly,  we  can  consider  two  models  of  languages,  English  and  French.  English 
is  a  federated  language;  it’s  a  mixture  of  borrowed  and  invented  parts,  to  which 
anyone  can  add  for  his  or  her  convenience.  It  would  be  a  mess  if  you  wanted  to 
administer  it,  but  it's  manifestly  extensible.  French  on  the  other  hand  is  protected 
bv  the  state,  its  purity  and  stability  a  source  of  pride  (and,  conversely,  woriy  about 
foreign  influences  on  modem  usage).  We  believe  that  there  is  an  underlying  cul¬ 
tural  difference  here  that  is  also  reflected  in  French  and  English  legal  and  engineer- 
ing  paradigms,  discussed  elsewhere. 

Agility  in  the  VE  context  means  the  ability  to  be  able  to  extend  your  own  reach 
without  undue  cultural  (and  other)  constraints.  And  we  think  that,  at  root,  the  oth¬ 
er  constraints  (at  least  the  non-physical  ones)  largely  follow  from  cultural  con¬ 
straints.  The  bottom  line  is  that  the  use  of  standards  (especially  STEP)  may  be  a 
good  idea  for  other  reasons,  but  they  have  nothing  to  do  with  agility. 

The  language  that  VE  agents  use  to  communicate  among  themselves  is  of  para¬ 
mount  importance.  But  requiring  that  language  to  be  standard  is  unagile.  Instead, 
we  need  a  language  that  is  adaptable  and  can  be  used  in  a  basic  way  to  describe 
more  complex  adaptations  on  the  fly. 

21.3  Hidden  Economic  Motivators 

[Cultural  factors  may  dominate  the  strategy  of  the  enterprise.  Some  examples.) 

Though  it  isn’t  the  goal  of  the  project  to  study  social/cultural  mohVators  in  the 
AVE  we  should  be  sensitive  to  them  where  they  are  apparent.  The  kind  of  motiva- 
tors’we  are  talking  about  are  those  which,  if  accommodated,  could  add  incentive 
to  AVEs.  This,  incidentally,  is  the  converse  of  barriers,  which  is  where  DoD  research 
projects  usually  start. 

AVE  motivators  all  seem  to  be  cultural  in  nature.  The  relationship  betwe^  cul¬ 
ture  and  commerce,  each  providing  the  major  force  for  change  in  the  other,  sh(^ 
be  no  surprise.  Commerce  is  an  older  and  more  fundamental  force  in  society  than 
■^ither  government  or  agriculture. 

'  Here  are  a  few  examples  of  such  motivators: 

^The  Software  Publishers’  Association  concerns  itself  with  the  pirating  of  soft- 
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ware.  Approximately  half  of  all  copies  ofshrinkwrapped  software  in  the  U.  S,  are 
stolen;  most  of  these  in  use  are  in  business.  It's  known  that  the  smaller  the  busi¬ 
ness,  the  higher  the  rate  of  payment.  So  this  suggests  a  likely  dynamic:  the  more 
that  organizations  are  aggregates  of  small  firms  instead  of  larger  groups,  the 
more  revenue  will  flow  into  software  publishers. 

Since  a  reasonable  estimate  of  the  lost  revenue  in  the  U.  S.  is  on  the  order  of  bil¬ 
lions,  AVEs  could  pump  large  amounts  into  the  business  software  market.  It 
should  be  expected  that  a  significant  percentage  of  those  dollars  would  go 
toward  shrinkwrapped  AVE-serving  software. 

^In  the  past,  a  job  with  a  big  corporation  meant  security.  That  is  no  longer  the 
case.  The  Department  of  Labor  reports  survey  results  showing  that  most  skilled 
and  educated  workers  would  prefer  to  work  for  smaller  companies  because  this 
would  make  them  feel  more  secure. 

Many  studies  have  shown  that  the  same  workers  are  more  productive  and  innova¬ 
tive  in  small  company  settings  than  in  large  ones.  So  individual  desire  for  job 
security  (or  some  related  benefit  like  supervisory  justice)  can  be  a  motivator. 
^Department  of  Commerce  studies  have  shown  that  consumer  preference  for 
national  brands  is  based  on  the  perception  of  modern  management  rather  than 
the  facts.  In  other  words,  consumers  buy  Japanese  cars  more  because  they 
believe  that  they  must  be  better  because  the  Japanese  the  management  style  is 
presumed  to  be  more  modern. 

So  a  VE  might  adopt  agile  practices  in  part  because  of  the  panache,  the  excite¬ 
ment  that  It  adds  to  the  customer’s  experience. 

A  corollary  is  that  perceptions  are  highly  influenced  by  cultural  factors.  It  could 
be  that  AVEs  are  sufficiently  modern  that  the  modernity  itself  could  attract  con¬ 
sumers  eager  to  see  innovation  in  domestic  business  methods.  This  can  be  seen 
m  the  popularity  of  Saturn  cars;  people  buy  them  not  merely  because  of  intrinsic 
value,  but  because  they  believe  that  a  better  system  must  make  better  cars. 

All  of  these  are  social  effects  with  economic  consequences  that  could  add  incen¬ 
tive  for  the  AVE.  With  a  few  strong  drivers  of  this  type,  agility  may  not  need  lob¬ 
byists  or  evangelists.  Evaluating  such  factors  is  not  the  target  use  for  the  metrics 
But  It  surely  would  be  helpful  to  apply  the  social/cultural  metrics  to  documenting 
and  evaluating  factors  such  as  these. 

It’s  an  area  for  future  study. 

21.4  The  Role  of  Organized  Learning 

(An  agile  organization  is  one  that  has  a  learning  culture.) 

Agility  Is  the  ability  of  an  organization  to  adapt.  The  AVE  increases  this  ability 
by  appropri  ately  adapting  the  nature  of  the  organization  itself.  Agility  boils  down 
.to  how  well  (meaning  quickly,  cheaply,  and  repeatedly)  an  organization  can  learn 
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Learning  is  essentially  a  social  drama.  The  metrics  must  measure  the  ability  of 
an  organization  to  learn.  We  hope  that  they  also  provide  a  scaffolding  for  others 
to  use  in  determining  the  learning  path  for  specific  types  of  change. 

21.4.1  Honesty  and  the  Investment  Community 

(The  ability  to  judge  itself  seems  an  agile  cultural  trait.) 

One  community  interested  in  these  metrics  is  the  investment  community.  The 
reason  is  simple  to  see.  That  community  already  has  sufficient  metrics  to  deter¬ 
mine  how  profitable  an  enterprise  currently  is.  Our  new  metrics  (at  least  when  ap¬ 
plied  on  the  strategic  scale)  can  evaluate  how  profitable  an  enterprise  is  likely  to 
become  when  situations  change;  and  change  is  expected  in  many  sectors. 

For  example,  Warren  Buffet  (perhaps  the  world’s  most  successful  investor), 
above  all  else,  explicitly  assesses  an  organization's  ability  to  resist  the  institutional 
imperative.  This,  he  believes,  is  manifested  in  two  qualities:  the  ability  to  learn  and 
the  quality  of  being  honest.  These  two  capacities  are  highly  interdependent. 

The  focus  on  honesty  results  from  the  reward  system  being  used  to  give  incen¬ 
tive  for  learning.  If  your  organization  is  not  honest,  it  does  not  have  a  basis  for 
building  a  reward  system  that  is  capable  of  promoting  learning. 

An  area  for  further  study. 

21.4.2  The  Importance  of  Dyadic  Communication 

(Even  in  the  largest  enterprise,  most  collaboration  is  between  two  people,  a  situation  where  social  dynamics 
dominate.) 

Essentially  all  of  the  dynamics  that  interest  us  involve  communication  among 
parties,  and  most  of  that  is  specifically  between  two  parties.  To  an  astonishingly 
high  degree,  this  is  between  two  persons,  often  as  representatives  of  two  organi¬ 
zations.  Educated  estimates  range  to  more  than  half  of  all  human  collaboration  Is 
conducted  through  dyadic  (i.e.,  two-way)  communication  between  persons. 

It's  proposed-and  we  accept~that  non-dyadic  agreements  are  derived  from,  or 
special  cases  of,  the  person-to-person  interaction.  For  example,  we  observe  that 
company  to  company  negotiations  on  a  contraa  use  dynamics  that  are  similar  to, 
or  are  composed  of,  person  to  person  dyads. 

We  are  greatly  interested  in  how  these  dyadic  interactions  occur.  Since  our 
model  is  based  on  transactions  between  two  entities,  the  metrics  provides  a  basis 
for  someone  to  leverage  these  cultural  insights.  Also  an  area  for  ftirther  study. 
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22  Trust 


(Trust  seems  to  be  a  common  cultural  descriptor  of  agile  systems.  We  explore  the  idea  in  this  section.) 


22.1  Background 

|We  exclude  social  and  cultural  issues  from  our  first  shot  at  metrics,  but  are  advised  they  are  unavoidable.) 

The  existing  metrics  are  first-order  metrics  and  in  the  first  edition  exclude  social 
and  cultural  Issues.  A  central  issue  concerning  both  is  the  property  of  trust.  So  the 
Agile  Virtual  Enterprise  Focus  Group,  the  email  discussion  group  and  the  project 
looked  at  Trusted  Agents.  In  addition  to  a  large  number  of  other  insights,  three 
specific  topics  emerged.  This  short  report  records  the  highlights  of  those  topics. 
They  deal  with  1)  the  difference  between  confidence  and  trust;  2)  the  difference 
between  trusted  agents  and  trusted  communication;  and  3)  trust  metrics. 

22.2  An  Example  of  the  Problem 

(An  example  of  an  apparently  logical  aaion  undermines  trust.  There  is  a  difference  between  trusting  agents  and 
trusting  the  channels  among  agents,) 

Sirius-Beta's  second  introduction  to  enterprise  engineering  was  the  role  it 
played  in  automating  shipboard  logistics.  The  problem  was  simple,  it  was  thought. 
Until  the  mid-eighties,  ships  kept  records  on  their  spare  parts  and  manuals  inven¬ 
tory  in  pencil  on  index  cards  in  huge  rolodexes.  For  all  the  obvious  reasons,  the 
records  were  poor,  and  difficult  to  track  at  the  fleet  level.  The  result  was  that  few 
ships  had  what  they  needed  and  many  things  that  they  didn't.  On  whole,  there  was 
a  vast  waste  in  or  obsolete  parts  in  the  system,  which  not  only  cost  the  taxpayer 
money  (hundreds  of  millions),  but  took  up  valuable  space  and  weight  on  the  ships. 

The  solution,  it  seemed  so  logical,  was  to  install  modern  computers  on-board  to 
perform  record-keeping.  This  was  accomplished  at  some  cost,  collecting  along  the 
way  sources  for  many  stories.  The  one  that  Is  cogent  is  that  the  computer  systems 
were  vehemently  fought  by  ship's  officers,  and  that  in  the  first  decade  after  instal¬ 
lation,  fleet  spares  readiness  went  way  down.  It  took  substantial  effort  to  discover 
what  was  going  on. 

What  had  happened  Is  that  there  were  two  spare  parts  distribution  networks. 
The  official  one,  which  was,  then  and  now,  broken,  and  an  unofficial  one.  The  un¬ 
official  one,  which  was  the  primary  channel  for  key  items,  depended  on  slack  in 
accountability  of  the  official  one.  Ship's  officers  developed  communication  net¬ 
works  based  on  trust.  Those  networks  were  an  underground  barter  system  for 
trading  parts,  which  had  evolved  the  ability  to  adapt  while  in  extended  cruises. 

We  understood  the  need  to  Improve  trust  in  the  node  of  the  system,  the  infor¬ 
mation  support  to  the  decisionmaker.  It  was  a  good  thing  to  improve  the  quality 
of  the  knowledge  about  (trust  in)  what  each  ship  had,  and  this  was  true  for  both 
the  shipboard  officers  and  the  shorebased  fleet  logistics  planners. 

But  we  misunderstood  the  nature  of  the  communication  channels  between 
nodes.  Indirectly,  we  empowered  the  official  communication  channels,  the  ones 
which  allowed  shore-based  clerks  to  carefully  control  what  went  where.  These 
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were  not  then,  nor  now  trusted  to  the  job  correctly.  We  failed  to  appreciate  the 
power  of  the  adaptive  federation,  agility,  among  officers  that  made  the  system 
work  by  applying  local  knowledge  and  domain  skills. 

This  understanding,  that  there  is  one  kind  of  trust  in  nodes  (agents)  and  another 
in  communication  channels  between  nodes,  is  captured  in  the  sections  that  follow. 
It  would  have  been  far  better  for  us  to  improve  the  collaboration  technology  first, 
perhaps  turning  a  blind  eye  to  the  unofficial  parts  bartering,  then  later  have  re¬ 
sponded  to  increasing  the  confidence  of  official  accounting  systems. 

Incidentally,  this  isn't  just  about  spare  parts.  Naval  warfare  is  a  highly  distributed 
affair,  and  trust  among  ships  (meaning  their  officers)  is  essential  in  combat  strate¬ 
gy.  We  found  that  the  primary  way  this  multipurpose  trust  was  maintained  and 
tested  was  through  this  huge  unofficial  parts  network,  which  was  highly  personal¬ 
ity-oriented. 

We  actually  hurt  the  ability  to  adaptively  collaborate  in  combat,  perhaps  in  a  sig¬ 
nificant  way.  Fortunately,  the  system  hasn't  been  tested. 

22.3  Confidence  and  Trust 

[There  are  two  definitions  of  trust.  We  contrast  the  two  here.) 

Substantial  effort  was  spent  by  the  extended  AVE  Focus  Group  in  trying  to  pin 
down  a  definition  of  trust  and  surprising  difficulty  was  encountered.  Two  camps 
emerged  which  can  be  roughly  characterized  as  those  for  whom  confidence  was  an 
adequate  synonym,  and  those  for  whom  it  wasn't. 

22.3.1  Confidence 

[One  kind  of  trust  is  expected  repeatability.  But  this  has  problems  when  conditions  change.) 

Confidence  in  an  agent  or  phenomenon  means  that  it  is  consistent  and  predict¬ 
able,  based  on  inductive  evidence.  It  is  implicit  in  all  this  that  you  know  what  the 
behavior  is.  In  other  words,  if  you  can  predict  behavior,  you  can  trust  the  agent  (or 
laws)  that  drive  it. 

Sunrise  is  predictable  and  consistent,  so  it  can  be  said  that  one  can  trust  the  sun 
to  rise  each  morning.  Really  what's  being  said  is  that  the  sun  is  an  imputed  agent 
of  certain  laws,  and  that  you  have  trust  in  the  laws  of  solar  physics.  Trust  in  this 
sense  means  confidence.  But  laws  of  physics  don't  change,  business  criteria  do.  In 
physics,  one  can  impute  an  agent  which  is  trusted.  For  instance,  people  often  con¬ 
veniently  pretend  that  the  sun  causes  its  own  rising.  But  one  cannot  do  this  in  busi¬ 
ness  because  the  laws  are  dynamic  and  it  is  important  to  understand  the  real 
physics  at  work. 

In  a  business  environment,  confidence  could  mean  that  a  prime  has  trust  in  a 
supplier  because  that  supplier  has  consistently  done  well.  Or  the  prime's  buyer 
|trusts  the  supplier's  salesperson  for  the  same  reason. 

There  are  two  limits  to  this  definition,  and  they  are  related.  What  if  performance 
in  all  past  experiences  is  not  an  indicator  of  how  the  supplier  will  perform  in  the 
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Repeatability 


Insight 


Works  with  contin¬ 
uous,  static  situa¬ 
tions,  and  known, 
stable  agents. 


Works  with  un¬ 
known  agents  in 
dynamically  chan^ 
in^  situations. 


Figure  22-1  :Two  Definitions:  Inductive  (Confidence)  Supports  the  More  Formal 

Definition 

future  when  conditions  change?  To  deal  with  these  situations,  one  needs  a  deduc¬ 
tive  measure  of  trust,  not  an  inductive  one. 

The  second  limit  is  one  of  representation:  trust  in  one  agent  may  not  mean  that 
an  associated,  relevant  portion  of  the  system  can  be  trusted.  For  instance,  you  may 
know  a  CEO  or  marketing  manager  well  and  have  confidence  in  their  honesty,  etc. 
But  does  that  translate  Into  high  confidence  in  their  company's  abilities? 

No,  it  does  in  the  physical  world  because  the  nature  of  physical  causality  is  such 
that  you  can  designate  an  agent  (the  sun,  or  gravity)  to  stand  for  the  whole  system. 
But  in  the  business  enterprise,  things  are  not  so  well  behaved.  Confidence  Is  not  a 
sufficiently  robust  definition  of  trust  purely  on  the  limits  of  induction  extrapolated 
into  unknown  conditions,  in  other  worlds,  the  area  of  agility. 

Also,  using  this  notion,  there  are  difficulties  in  who  could  be  designated  the 
agent  which  represents  the  portion  of  the  (business)  system  which  is  of  Interest. 

22.3.2  Trust 

(Another  notion  of  trust  is  based  on  knowing  how  someone  might  behave.  This  is  better  for  agility.) 

Another,  better  notion  of  trust  Is  based  on  deductive  criteria.  On  its  face,  this  is 
what  we  would  prefer  in  engineering  agile  business  systems  (as  with  non-business 
systems).  Using  this  notion,  an  agent  Is  trusted  if  he/she  is: 

4  Accountable:  this  Is  another  way  of  saying  that  the  agent  is  causally  coupled 
Into  the  processes  in  a  tight,  understandable,  causal  way.  (We  expand  this  one 
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issue  below  in  talking  about  channels.) 

4Timely:  the  agent's  insights  are  based  on  the  current  situation, 

^Accessible:  the  agent,  specifically  the  agent's  insight,  information  or  knowledge 
is  accessible  to  you  at  your  convenience. 

4 Accurate:  the  agent's  insight  is  correct.  It's  the  truth. 

4Complete:  the  agent's  insight  has  all  of  the  necessary  context  and  qualifiers  to 
allow  you  to  perform  your  system-level  analysis. 

4Uncorrupted;  the  agent's  insight  does  not  have  junk  mixed  in  with  the  truth. 

For  example,  take  a  supplier's  marketing  representative.  (Note,  all  mainstream 
examples  would  involve  agents  as  people.)  We  could  really  like  this  person,  appre¬ 
ciate  his/her  ethics,  and  have  had  nothing  but  good  experiences  so  far,  and  still  not 
have  trust  in  the  company  under  an  unusual  demand.  (Not  having  trust  is  simple 
neutrality  as  opposed  to  negative  trust:  trusting  that  the  company  will  screw  up.) 

For  the  marketing  agent  to  be  accountable,  he  or  she  would  have  to  fully  know 
and  honestly  represent  the  capabilities  of  the  supplier  to  your  own  level  of  detail. 
The  information  would  be  timely  if  it  represents  the  current  state,  not  an  extrapo¬ 
lated,  perhaps  hoped-for  state.  It  will  be  accessible  if  you  can  get  what  you^need 
when  you  need  it.  Your  trust  in  completeness  and  uncorruptness  means  you're  get¬ 
ting  the  whole  truth  and  nothing  but  the  truth  (see  below.  If  all  these  things  are 
true,  you  have  a  trusted  agent  as  a  collaborator  in  engineering  your  supply  chain. 

Incidentally,  our  definition  of  deductive  trust  includes  the  requirement  that  the 
information  be  accurate,  complete,  and  uncorrupted.  This  same  notion  is  captured 
in  the  oath  that  witnesses  take  in  U.  S.  courtrooms  in  order  to  establish  trust.  The 
witness  swears  to  tell  the  truth,  the  whole  truth,  and  nothing  but  the  truth.  Whats 
the  difference? 

The  truth  means  that  what  will  be  reported  will  accurately  reflect  what  is  known. 
The  whole  truth  meant  that  the  statement  will  be  complete.  An  omitted  but  essen¬ 
tial  qualifier  or  context  for  example  could  completely  change  a  true  statement's 
meaning.  While  the  witness  told  the  truth,  it  could  be  missing  key  ingredients 
which  have  the  effect  of  making  the  true  statement  less  true.  Nothing  but  the  truth 
is  the  reverse,  where  the  witness  adds  statements  which,  while  not  untrue  in  them¬ 
selves,  add  false  qualifiers  or  context. 

This  is  the  notion  of  deductive  trust  which  we  use  in  the  reporting  the  following 
additional  observations. 

22.4  Agents  and  Channels 

(Trust  in  agents  is  different  than  trust  in  the  communication  channel  among  agents.| 

There  is  a  distinction  to  be  made  between  the  agent  and  the  channel  through 
which  you  communicate  with  the  agent.  Each  has  its  own  type  of  trust.  You  have 
>to  trust,  for  instance  that  the  sales  manager  of  your  supplier  knows  what's  up,  as 
'well  as  having  to  trust  that  the  email  that  you  got  from  him/her  is  at  sufficient  fi¬ 
delity.  One  is  trust  in  an  agent,  one  trust  in  a  communication  channel. 
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22.4.1  Agents 

[There  are  three  types  of  agents.) 

We  delved  into  this  somewhat  because  the  focus  on  the  communication  seems 
to  be  the  second  main  distraction  in  this  whole  dialog  (the  first  being  trust  as  con¬ 
fidence),  Trust  in  communication  is  where  a  lot  of  VE  effort  is  being  placed:  assur¬ 
ing  fidelity  and  controlling  access  through  the  channel,  the  whole  Electronic 
Commerce  diversion.  But  those  are  relatively  simpler  issues;  the  key  payoff  is  in 
whether  the  agent  is  a  trusted  one. 

WeVe  broken  down  the  agents  into  three  types: 


4The  Sensor:  this  agent  is  alert  to  all  the  factors  that  are  in  it's  assigned  domain. 
Trust  in  this  type  of  agent  means  that  the  signal  is  true.  If  kids  stop  buying  white 
sneakers  in  favor  of  blue  ones,  you  want  to  be  able  to  trust  that  your  market 
researcher  detects  the  trend  (and  doesn't  signal  false  trends). 

^The  Analyzer:  an  agent  that  determines  whether  a  change  (or  other  input  from 
the  sensor)  is  Important  to  the  enterprise  and  in  what  way.  A  trusted  analyst  Is 
rare  unless  they  stick  to  the  most  mundane  of  factors  (cost,  quality)  and  stay 
close  to  home  in  terms  of  existing  products  and  strategies.  This  agent  is  the  tar¬ 
get  for  the  agility  metrics  project,  the  metrics  intended  to  increase  the  ability  to 
audit  reasoning  about  strategies  of  change,  thereby  increasing  trust. 

^The  Actor:  the  agent  that  triggers  and  controls  the  process,  which  in  the  agility 
sphere  is  a  process  of  change.  A  trusted  aaor  is  one  that  takes  the  right  action 
and  does  it  effectively. 

Often  two  roles,  and  rarely  three,  are  played  by  a  single  person. 

So,  there  are  three  types  of  agents  and  three  criteria  by  which  they  become 
trusted  agents. 

22.4.2  Channels 

^  [Agility  is  related  to  the  connectivity  among  agents.) 

The  agents  are  connected  to  each  other  by  communication  channels,  both  hor¬ 
izontal  channels;  links  among  sensors,  analysts  and  actors,  and  vertical  channels 
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which  link  agents  to  form  a  the  VE,  or  an  enterprise  for  that  matter.  All  of  these 

type  regardips  of  what  agents  they  connect.  All  are  sub- 
tedinofogiS"^^  problems,  and  probably  all  addressable  by  the  same  policies  and 

Usually,  the  vertical  links  in  a  VE  involve  only  aaor  agents.  If  many  of  those  ac¬ 
tors  are  not  conneaed  to  analysts,  the  system  cannot  be  agile.  Probably,  what 

nds^buHr^^*^*^"^^  including  more  agile,  is  if  there  is  not  only  many  chan- 

^thcy  link  scross  3II  three  types  of  agents 
^they  cross  functional  and  company  boundaries 

Athene  is  a  high  level  of  trust  in  the  agents  (and  of  course  the  channels  too) 
agentT^^^*^^  ^  of  thumb  for  AVEs  Is  to  have  high  connectivity  and  trust  among 

In  most  cases,  a  network  of  agents  operates  at  the  lowest  level  of  trust  of  anv  of 
Its  components,  unless  there  exist  some  metrics  to  evaluate  the  trust  of  specific 
I  messages  from  that  agent  accordingly.  Current  metrics,  not 

nZl'rf  u  elements  of  the  channel  and  the  simple  notion  of  trust  we 

noted  above  called  (inductive)  confidence. 

22.5  Trust  Metrics 

|Our  basic  method  might  be  expanded  to  provide  metrics  for  trust  in  an  enterprise,  which  are  also  tagged  to 
processes  and  agents.) 

It  IS  not  Within  the  scope  of  the  metrics  project  to  address  trust  metrics,  mst  met¬ 
rics  of  agility.  But  it  is  entirely  possible  that  much  of  the  work  on  agility  metrics 
can  be  leveraged  to  develop  metrics  for  trust. 

Our  new  agility  metrics  are  based  on  an  information-theoretic  idea  that  the 
more  complex  a  communicative  (functional)  network  is  in  certain  ways,  the  more 
resistant  to  change  it  is.  Among  all  the  complexity  metrics  that  exist,  weVe  dis¬ 
tilled  some  that  indicate  this  resistance.  These  themselves  are  functions  which  we 
can  manipulate  m  mathematical  ways  that  are  being  explored  by  our  Tool  Strategy. 

The  information-theoretic  view  depends  on  breaking  business  processes  down 
into  agems  and  communicative  acts.  Agents  in  that  view  are  the  same  as  the  agents 
we  describe  above.  Communicative  acts  follow  the  channels  we  described  above. 

In  fact,  the  agility  metrics  deal  with  measuring  the  connectedness  of  agents  but 
depend  on  a  single  level  of  trust  among  all  agents.  ^ 

However,  this  breakdown  of  agents  and  channels  is  just  what  we've  been  using 
m  our  trust  discussion.  It's  likely  that  much  of  the  foundation  of  the  MAVE  proiect 
can  be  used  by  someone  looking  at  trust  metrics: 

^The  mapping  of  business  processes  to  agents  in  a  practical  way  (via  the  AVE 
Focus  Group  Reference  Model). 

^The  understanding  used  to  map  theoretical  complexity  metrics  into  specific 
business  strategies 
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Figure  22-3;Different  Types  of  Channels  Interconnect  the  Agents  in  an  Enterprise 

^The  anticipated  advances  in  modeling  so/i  (social  and  cultural)  processes  which 
come  from  the  marriage  of  communicative  acts  and  situation  theory. 

Incidentally,  the  case  study  provides  some  information  on  the  cost  of  creating 
this  breakdown,  which  would  be  reusable  for  trust  evaluation. 
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We  decompose  aqer\t  packets  and  measure  topology 
of  communicative  acts 


Trust  metrics  would  be  top  down,  and  leverage 
different  topology  complexity  measures. 

Figure  22-4:Our  Decomposition  of  the  Enterprise  into  Conversations  among  Agents 

can  Support  Clustering  for  Trust  Metrics 
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23  Cultural  Drivers  for  Legal  Issues  in  the  Defense  Community 

(We  suggest  a  source  for  two  confliaing  paradigms  which  haunt  the  defense  industrial  base.) 


23.1  A  Key  Difference:  The  English  and  French  Engineering  Paradigms 

[The  French  and  English  have  wholly  different  approaches  to  engineering.  These  are  culturally  based.  The  U.  S. 
civil  sector  inherited  the  English,  while  the  military  sector  inherited  the  French.) 

Our  mandate  included  looking  at  potential  differences  between  the  civil  and  de¬ 
fense  manufacturing  communities.  WeVe  done  so,  and  concluded  that  the  differ¬ 
ences  are  in  the  contractual  and  regulatory  infrastructure.  But  what  causes  this  are 
deep-seated  cultural  differences.  This  can  be  seen  in  engineering  approaches. 

It  happens  again  and  again  that  engineers  from  a  commercial  perspective  look 
at  a  problem  and  produce  differing  results  from  those  of  engineers  associated  with 
defense  or  government.  Variations  on  large  water  projects,  nuclear  power  instal¬ 
lations,  and  the  Strategic  Defense  Initiative  are  a  few  of  the  generally  recognized 
high-difference  areas.  Certain  of  the  less  public  ones  involve  environmental  and 
transportation  engineering  risks,  and  some  argue  that  the  effect  is  also  seen  in 
health  and  criminal  risk  analysis. 

Of  the  differences  which  one  encounters,  those  which  are  most  interesting  are 
not  the  ones  arising  from  varying  priorities  or  politics,  but  differences  that  run  so 
deep  in  world  views  that  they  seem  to  underlie  the  actual  mathematics.  We  count 
ourselves  among  those  who  believe  that  the  difference  can  be  traced  to  a  well-rec¬ 
ognized  difference  in  engineering  traditions  between  18th-century  France  and  En¬ 
gland. 

In  England,  engineering  grew  out  of  a  strong  guild  tradition,  which  stressed 
commercial  practicality.  Engineers  and  civil  servants  rarely  mixed.  Even  in  the  mil¬ 
itary,  where  the  use  of  engineering  skills  was  heavy,  the  tradition  was  to  keep  a 
distinction  between  warriors  and  engineers  and  to  utilize  contractors  where  pos¬ 
sible  for  engineering  tasks.  Having  engineering  skills  provided  scant  introduction 
to  either  military  or  political  society. 

In  contrast,  French  engineering  touted  its  origins  in  the  mathematical  elite, 
many  of  whom  in  the  eighteenth  century  were  French.  Military  officers  were  ex¬ 
pected  to  be  competent  engineers,  and  civil  and  engineering  life  were  strongly  in¬ 
termingled.  For  example,  the  French  established  the  world’s  first  engineering 
university  in  1794,  the  Ecole  Polytechnique,  on  Rue  Descartes  (see  (DEVL971!)  no 
less. 


Championed  by  Napoleon,  the  school  and  the  graduates  were  hailed  as  the  hen 
with  the  golden  eggs  for  France.  That  literally  has  been  their  symbol  since.  This 
was  in  fact  a  military  school;  aspiring  engineers  wore  uniforms,  carried  swords, 
and  drilled.  The  lower  tier  students  studied  at  the  Ecole  Centrale  des  Arts  and  Man¬ 
ufactures  and  were  destined  for  mere  commerce.  The  upper  tier  went  on  to  grad¬ 
uate  work  at  the  Ecole  Fonts  et  Chaussees  (bridges  and  embankments)  and  became 
known  as  ingeniers  de  I’etat.  These  men  had  profound  influence  in  the  bureaucra¬ 
cy,  and  hence  over  all  of  French  society. 
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The  French  model  of  engineering,  therefore,  evolved  with  large,  often  extremely 
expensive,  ambitious,  and  visible  projects.  These  were  designed  to  serve  the  soci¬ 
ety  as  a  whole,  and  the  benefit  to  the  engineers  was  in  advancing  society.  It  would 
have  been  considered  crass  to  have  applied  values  of  personal  profit  to  any 
project,  which,  of  course,  was  the  English  default. 

The  French  invented  the  engineered  organization~the  bureaucracy-but  only 
later  in  far  richer  and  larger  countries  (The  U.  S.  and  USSR)  would  their  ideas  on 
both  engineering  and  civil  management  become  supercharged  as  the  prime  tech¬ 
nique  for  conducting  the  cold  war. 

Of  course,  being  an  English  colony,  America,  especially  New  England,  followed 
English  tradition  as  its  industries  grew  into  the  19th  century.  But  the  French  tradi¬ 
tion  was  inoculated  with  amazing  effectiveness  in  both  American  and  Russian  mil¬ 
itaries. 

Russian  czars  were  eager  to  europeanize  their  nation  and  so  entered  into  a  long 
exchange  program  which  continues  to  this  day.  Engineers  and  bureaucrats  were 
sent  to  France  for  study  at  the  Polytechnique  and  imported  the  paradigm  back  into 
their  country.  Surviving  the  revolution,  the  paradigm  was  well  suited  to  the  Soviet 
totalitarian  direction  events  took  and  especially  came  into  play  after  WWIl  as  the 
entire  country  had  to  be  re-engineered. 

Communism,  social  engineering  in  a  very  basic  sense,  can  be  linked  to  this  par¬ 
adigm,  and  many  believe  that  it  wasn't  war,  boneheaded  and  cruel  dictatorship,  or 
socialism  that  killed  the  Soviet  Union.  Instead,  it  was  their  blind  following  of  mas¬ 
sive,  centrally  managed  engineering  projects  for  the  common  good,  without  the 
feedback  loop  for  immediate,  finegrained  satisfaction  that  market  forces  provide. 
Perhaps  most  disastrously,  even  agriculture  was  centrally  engineered. 

At  any  rate,  the  British  model  dominates  American  commercial  life,  essentially 
all  of  our  economy,  and  has  been  quite  successful  because  innovation  has  been 
linked  to  personal  reward.  But  the  French  model  gained  a  toehold.  How  and  where 
(in  the  military)  is  instructive. 

The  U.  S.  was  losing  its  war  of  independence.  The  English  nearly  had  it  beaten, 
but  the  intervention  of  the  French  at  Yorktown  in  short  order  proved  decisive.  The 
primary  asset  the  French  sent:  military  engineers  and  sophisticated  materiel.  The 
apparent  lesson  was  not  lost  on  General  Washington,  and  among  the  first  acts  of 
the  new  nation,  which  he  ramrodded,  was  the  decision  in  1778  to  establish  an  en¬ 
gineering  school.  This  was  finally  established  at  West  Point  NY  in  1802. 

Modeled  directly  after  the  Ecole  Polytechnique,  the  school  was  dominated  by 
imported  French  professors.  Its  mission:  to  produce  engineers  for  the  nation,  inci¬ 
dentally  through  the  army,  which  was  seen  as  necessarily  synonymous  with  tech¬ 
nological  progress.  Of  course,  over  the  next  few  decades,  more  and  more  non¬ 
engineering  and  scientific  subjects  were  introduced  until  we  have  its  current  state. 

I  But  meanwhile,  the  English  inspired  idea  of  practical  science  caught  on  in  the  U. 
S.  commercial  sector.  The  two  traditions  competed,  each  dominating  in  different 
regions  of  the  country.  The  French  model  was  adopted  in  the  north,  with  the  es¬ 
tablishment  of  an  engineering  school  at  Rensselaer  Institute  in  1835.  By  midcentu- 
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ry,  Rensselaer  was  the  leading  engineering  school  in  the  country.  The  reason  this 
French  approach  flourished  was  the  same  as  for  the  school’s  founding  and  success- 
-the  railroad. 

Railroad  monopolies  (for  our  purposes,  the  same  as  government  agencies)  need¬ 
ed  engineering  skills  to  build  a  vast  network,  including  many  challenging  bridges. 
The  idea  of  large,  centralized  projects  serving  the  institution  was  very  French. 

In  the  south,  the  English  model  started  to  grow  from  grassroots  need.  The  two 
first  universities,  in  fact  the  centers  of  schooling  in  the  south,  were  the  Universities 
of  Virginia  and  Alabama.  Their  model  of  commercially-driven  engineering  directly 
contrasted  to  that  of  West  Point  and  Rensselaer  and  was  so  noted  at  the  time  in 
competitive  recruiting  pamphlets. 

Alabama’s  initiative  was  destroyed  by  the  civil  war  and  never  recovered,  and  it 
is  known  more  widely  today  as  an  athletic  franchise.  But  what  happened  in  Virginia 
is  really  interesting.  The  head  of  their  practical  science  program,  in  fact  the  only 
full-time  professor  in  it,  was  a  young  fellow  named  William  Barton  Rogers.  He  was 
trained  at  William  and  Mary.  (Together  with  Harvard,  they  were  the  only  two  ad¬ 
vanced  schools  in  colonial  times.)  His  father,  being  a  chemistry  professor  there, 
knew  Thomas  Jefferson  who  considered  the  founding  of  the  University  of  Virginia 
to  be  his  finest  achievement,  instructing  that  only  that  fact  appear  on  his  tomb¬ 
stone,  nothing  about  his  role  as  a  founding  father  of  the  U.  S.  (The  instructions 
were  not  followed.) 

Jefferson  believed  that  the  country  was  making  a  mistake  going  with  the  French 
model  at  West  Point.  He  had  spent  several  years  in  France  as  the  U.  S.'s  first  am¬ 
bassador  and  had  made  a  careful  study  of  their  model.  He  considered  it  insidiously 
undemocratic.  He  very  much  wanted  his  university  to  grow  as  a  school  based  on 
the  English  model  and  often  promoted  that  idea  at  William  and  Mary  to  the  senior 
Rogers  until  Jefferson  died  in  1826. 

So  here  was  Barton  Rogers,  leading  the  charge  at  the  University  of  Virginia  in 
1 846  trying  finally  to  do  so.  But  he  left.  The  University  had  hired  a  Jewish  professor 
that  year  to  teach  Hebrew  and  Greek  for  Biblical  study.  The  student  body  was  so 
intolerant  that  they  pistol-whipped  the  new  professor.  When  the  dean  passed  a 
rule  outlawing  guns  in  class,  unruly  students  shot  him!  This  thuggishness  coupled 
with  the  institution  of  slavery  was  too  much.  Rogers  decided  to  take  his  mission 
to  a  more  enlightened  locale. 

He  spent  a  few  years  proselytizing  this  idea  of  a  school  for  democratic/commer¬ 
cial  engineering  and  practical  science,  including  during  a  stint  as  president  of  the 
young  American  Association  for  the  Advancement  of  Science.  Finally,  he  estab¬ 
lished  MIT,  then  Boston  Tech,  which  quickly  became  very  strong,  and  providing  a 
model  for  linking  innovation  and  science,  which  permeated  through  civil  society 
and  commerce. 


Supporting  this  development  were  strong  Emersonian  ideas,  local  to  Boston,  of 
the  importance  of  individual  principle  and  intellect,  as  opposed  to  those  of  an  in¬ 
stitution.  Around  1880,  more  international  students  were  drawn  to  MIT  than  to 
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the  Polytechnique,  signaling  a  change  of  values  in  Europe,  the  emergence  of  the 
English  model  of  innovative  commerce. 

While  the  Russians  became  thoroughly  French,  the  U.  S.  developed  a  bicameral 
paradigm,  with  French  dominance  in  various  governmental  and  military  affairs. 
The  French  tradition  can  be  seen  through  the  large  centrally-run  projects  of  the 
Army  Corps  of  Engineers,  which  began  in  the  early  19th  century  with  a  national  sys¬ 
tem  of  canals  and  lighthouses,  and  was  revived  with  the  production  miracle  in  Day- 
ton  concerning  WWI  aircraft.  It  was  further  sustained  between  the  wars  by  large 
hydroelectric  programs  and  continued  through  the  nuclear  bomb  and  energy 
projects  on  through  to  the  Apollo  missions.  The  tradition  can  also  be  traced  world¬ 
wide,  with  the  French  often  leading  the  way,  as  with  the  Suez  and  Panama  canals. 

Such  influence  is  clear  today  in  every  U.  S.  weapon  system  and  throughout  the 
defense  industrial  base.  A  recognition  that  a  completely  different  engineering  par¬ 
adigm  is  at  work  becomes  a  prerequisite  before  any  enlightened  comparison  can 
be  made  between  business  processes  and  the  underlying  culture  in  the  defense  in¬ 
dustrial  base.  We  think  any  attempt  to  bring  commercial  practice  to  the  defense 
domain  should  acknowledge  the  200-year  battle  between  these  memes. 

Military  electronics  and  software,  for  example,  differ  from  their  commercial 
counterparts  in  profound  ways.  The  conventional  thinking  is  that  their  require¬ 
ments  are  different,  so  a  different  culture  has  emerged  in  response  to  each.  We 
propose  the  opposite-that  the  cultures  came  first. 

Notably,  whenever  agility  is  required  in  the  defense  base,  an  English-type  orga¬ 
nization  is  introduced  into  the  system.  Thus  the  nuclear  weapons  complex  has  its 
Sandia  Labs  and  the  defense  aircraft  has  (or  had)  the  Lockheed  Skunkworks. 

23.2  Lessons  for  Metrics 

IDefense  lack  of  agility  is  caused  by  French  at  the  top,  English  at  the  bottom  of  enterprises.) 

In  the  dominant  defense  (or  French)  model  the  product,  the  processes,  and  the 
skills  used  to  support  the  processes,  as  well  as  the  work  breakdown  of  the  process¬ 
es,  are  all  specified  by  the  customer  in  a  centrally-managed  top-down  fashion.  In 
the  commercial  (or  English)  model,  a  fine-grained,  bottom-up  collection  of  func¬ 
tions,  is  empowered  by  market  forces.  These  functions  are  empowered  to  change 
all  of  the  noted  items  (products,  processes,  skills,  work  breakdown)  in  a  way  that 
manifestly  results  in  better,  faster,  and  cheaper  products. 

So,  it  would  seem  that  a  lesson  emerges  here  for  agility  metrics  in  the  defense 
sector.  The  transactions  that  are  supported  must  include  those  that  deal  with  this 
idea  of  market  forces  (the  linkage  of  value  added  for  recompense)  adjusting  the 
processes.  For  example,  a  transaction  boundary  between  a  prime  and  a  subcon¬ 
tractor  is  less  agile  if  the  prime  insists  on  control  of  details  of  the  processes  that 
the  sub  uses. 

>  Consider  the  example  of  the  Sidewinder.  The  Soviet  AA-12  VE  ran  under  a 
French  paradigm  throughout  and  was  effective;  the  Israeli  VE  was  thoroughly  En¬ 
glish  and  was  equally  effective.  It’s  when  you  have  the  top  half  (customer  to  prime) 
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with  one  and  the  bottom  (prime  to  subs)  with  another  as  in  the  U.  S.  that  the  sys¬ 
tem  becomes  crippled.  Compare  the  French/English  breakdown  to  the  meme- 
classes  of  the  structured  controversy  brainstorming  method. 


“French”  Meme  “British”  Meme 


Customer/Prime  Prime/Supplier 

Figure  23-1  iFrench  Meme  from  DoD  to  the  Prime,  English  from  the  Prime  to  the 

Subcontractor 


23.3  Law  Follows  Engineering 

(The  two  engineering  paradigms  become  ensconced  in  two  differing  legal  systems,  also  culturally  based.  Case 
law  (as  in  the  movies)  is  a  trust-enabling  environmental  factor.) 


Around  the  world,  we  find  two  primary  models  of  how  law  is  built,  and  these 
differing  law  systems  correspond  closely  to  the  two  government/engineering 
trends  discussed  above. 

The  type  of  law  many  people  immediately  think  of  is  code.  This  originated,  as  far 
as  we  know,  from  such  early  examples  as  the  Babylonian  Code  of  Hammurabi,  and 
this  approach  became  incorporated  in  many  later  hierarchical  societies,  their  gov¬ 
ernments,  and  religions  (including  Judaism,  and  thence  to  Christianity  and  Islam). 

The  idea  is  that  some  wise  person  or  body  is  in  authority  to  make  law.  These 
(usually)  men  proscribed  conditions  relating  to  certain  situations.  If  a  new  situa¬ 
tion-one  not  originally  anticipated-arose,  the  authorized  body  would  expand  the 
code.  Code  was  the  basis  for  Greek  and  Roman  law,  which  has  been  inherited  by 
much  of  the  western  world. 


Opposed  to  code  is  an  idea  that  originated  with  Darius  (about  500  B.C.).  Darius 
organized  the  Persian  empire  based  on  the  idea  of  federating  many  states  (sa¬ 
trapies)  while  preserving  the  local  cultural  diversity.  The  idea  was  that  no  one 
could  make  comprehensive  law  from  the  top  down;  there  are  just  too  many  special 
conditions  and  local  exceptions.  So  the  idea  of  common  (or  case)  law  was  devel¬ 
oped. 


It  was  used  by  segments  of  European  societies  which  were  on  the  outside  fring¬ 
es  of  the  Roman  empire,  notably  the  Celts  (in  the  British  Isles).  Beginning  with  the 
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famed  Magna  Carta,  and  evolving  into  its  present  form  by  the  17th  century,  com¬ 
mon  law  made  a  comeback,  in  Britain  and  the  British  Empire. 

The  key  idea  is  that  a  jury  of  common  people  could  evaluate  a  situation  and  ex¬ 
tend  the  meaning  of  prior  law  as  made  by  a  legislature.  That  judgment  then  be¬ 
came  a  case.  Subsequent  juries  were  to  consider  both  the  original  law  and  the 
subsequent  case  with  equal  weight.  Over  time,  of  course,  the  cases  would  often 
grow  to  eclipse  the  original  law,  resulting  in  a  bottom-up,  dynamically-redefined 
basis  of  laws  that  were  self-adjusting. 

Several  advantages  resulted,  but  the  one  that  interests  us  here  is  the  simplicity 
of  contracts  that  this  allowed  which  we  noted  in  the  movie  example.  Instead  of 
having  to  write  a  contract  that  covered  all  possible  contingencies,  one  only  had  to 
record  what  was  really  intended  by  the  agreement.  The  large  body  of  cases  that 
was  presumed  to  exist  and  to  be  based  on  common  sense  justice,  instead  of  bu¬ 
reaucratic  foibles,  could  be  called  upon  to  adjudicate  differences  if  things  went 
wrong. 

This  increased  the  burden  of  the  trial  system,  but  greatly  decreased  the  burden 
on  the  contract  law  system. 

The  U.  S.  inherited  this  system  of  common  law  when  it  transformed  from  an  En¬ 
glish  colony,  one  of  only  a  few  countries  to  do  so.  Actually,  each  of  the  now  fifty 
states  individually  inherited  this  system,  and  have  evolved  fifty  similar  threads. 
Federal  law  issued  by  the  central  government  now,  however,  tends  to  be  code-ori¬ 
ented.  For  example,  the  Uniform  Commercial  Code  was  needed  to  expedite  inter¬ 
state  commerce,  and  it  deliberately  concentrated  all  facets  of  making  the  law  in  a 
few,  powerful  bodies. 

So,  today,  there  is  a  mixture  of  code  and  common  law  in  the  U.  S.  But  most  pro¬ 
visions  of  most  contracts  in  the  commercial  arena  rely  on  case-based  state  laws. 
Some  commercial  sectors  can  be  very  agile  in  their  contracting  practices  because 
this  situation  still  obtains.  The  bad  news:  Americans  go  to  court  more  than  anyone 
else.  The  good  news:  in  some  sectors,  the  decrease  in  the  cost  and  time  of  devising 
domestic  contracts  is  vastly  less  than  in,  say,  Germany  and  Japan,  our  current  in¬ 
ternational  competitors. 

This  is  a  system  in  which  whatever  lack  of  trust  among  the  parties  is  handled  by 
a  presumption  of  trust  in  the  case  law,  rather  than  in  the  corporate  lawyers.  We 
believe  this  to  be  a  structural  advantage  for  the  U.  S.,  and  especially  so  in  the  AVE 
context. 


Defense  contracts  not  only  are  code-based,  but  more  centrally-mandated  than 
any  other  sector  of  the  economy.  The  contracts  are  based  on  code,  the  Federal  Ac¬ 
quisition  Regulations  (FAR).  Worse,  the  combination  of  the  French  engineering 
paradigm  results  in  every  detail  of  the  product  and  process  being  detailed  in  code, 
through  specifications. 

Engineering  decisions  about  processes,  sldlls,  and  work  breakdown  which  else¬ 
where  are  fluid  are  captured  explicitly  in  the  contract  and  supporting  law.  The  re¬ 
sult  is  a  brittle,  unagile  system  that  cannot  respond,  for  example,  to  a  severe 
missile  threat  in  a  timely  way. 


Fcimury  15,  1997 


223 


Part  3,  Soft  Modeling 


We  believe  that  these  competing  influences  cannot  be  wished  into  harmony.  In¬ 
deed,  many  benefits  result  from  the  institutions  that  exist.  The  challenge  is  instead 
to  create  greater  agility  within  the  existing  situation. 
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24  High  Concept  in  the  Supply  Chain 

jWe  return  to  movies  to  examine  lightweight  contracts  as  a  portable  technique.) 


24.1  Background 

|We  revisited  the  movie  contacts.) 

Consider  this  as  a  continuation  of  the  Whaling  Story.  In  that  story,  we  suggested 
that  the  U.  S.  film  industry  was  both  relatively  agile  and  a  good  example  of  contin¬ 
ually  formed  Virtual  Enterprises.  We  proposed  that  though  successful,  this  was 
somewhat  accidental,  relying  on  lightweight,  code-based  VE  association  contracts. 
It  seemed  then  that  there  were  some  elements  in  this  natural  evolution  that  could 
be  engineered  into  other  industry  sectors,  but  the  point  of  our  effort  was  else¬ 
where,  in  developing  metrics. 

Since  then.  I’ve  burrowed  deeper  into  the  situation,  developing  and  exercising 
insider  contacts.  All  of  this  has  been  more  difficult  than  you  would  think,  because 
the  agility  evolved  rather  than  being  engineered,  as  we  propose  for  example  in  the 
defense  aerospace  sector.  Few  movie  managers  know  what’s  going  on  at  the  level 
that  we  find  useful.  Much  of  what  follows  was  jointly  discovered  by  us  working 
with  them. 

Elsewhere,  we  report  on  Trusted  Agents,  with  much  of  the  discussion  concerned 
with  how  an  AVE  is  formed.  So,  in  revisiting  the  movie  business,  we  wanted  to  par¬ 
ticularly  touch  on  what  we  could  take  away  in  engineering  an  agile  supply  chain,  an 
AVE,  and  also  contribute  to  the  discussion  on  trust  and  change  concerning  agents. 

24.2  The  Movie  Industry  as  a  Prototype 

[The  Japanese  consider  the  movie  business  a  portable  prototype,  both  after  the  war  and  more  recently.] 

A  brief  history:  not  so  long  ago,  the  30’s,  the  movie  industry  was  configured  like 
today’s  automobile  and  aerospace  industries.  The  market  was  dominated  by  a  very 
few  large,  stable  companies.  The  big  five  were:  Lowes/MGM,  Paramount,  RKO, 
Twentieth  Century-Fox,  and  Warner  Brothers.  They  were  deeply  vertically  integrat¬ 
ed,  including  control  of  the  distribution  by  ownership  of  theaters. 

Competition  among  them  drove  them  to  what  today  we  call  lean  manufacturing 
practices:  flat  organizations,  prequalified  suppliers  (in  which  they  often  had  an  in¬ 
terest),  a  version  of  just-in-time  practices.  They  were  leaders  in  novel  accounting 
practices,  using  what  clearly  today  can  be  seen  as  activity-based  costing  (but  with¬ 
out  the  glitz). 

The  height  of  this  trend  continued  through  World  War  II.  After  the  war,  Japan 
had  the  opportunity  to  engineer  an  industrial  policy.  We  were  told  by  a  key  man 
in  devising  that  policy  that  they  studied  and  refined  techniques  from  three  sourc¬ 
es: 

}  4The  British  system  of  civil  service  and  empire  governance:  This  system,  which  the 
British  based  on  Persian  models  had  been  internalized  during  the  war  to  facilitate 
their  imperial  ambitions.  But  because  of  the  way  they  mix  government  and  indus- 
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try,  it  became  entrenched  in  business.  Key  discriminators  here  are  flat  organiza¬ 
tions  and  decentralized  power. 

4The  U.  S.  food  distribution  system:  The  just-in-time  movement  from  California, 
where  most  of  the  produce  was,  to  the  East  Coast,  where  most  of  the  people 
were  was  heralded  world-wide  as  a  miracle. 

(Incidentally,  current  attention  is  focused  on  the  Iranian  food  distribution  sys¬ 
tem.  In  the  U.  S.,  everyone  along  the  literal  food  chain  can  get  paid  when  their 
product  or  service  is  delivered,  because  money  is  borrowed.  But  in  Iran,  Islamic 
law  forbids  usury.  There  is  an  advanced  experiment  underway  that  makes  each 
member  of  the  supply  chain  a  partner  in  shares,  who  gets  reimbursed  when  the 
product  is  sold.  The  value  of  the  product  (including  how  much  survives  the  pipe¬ 
line)  isn’t  resolved  until  the  point  of  final  sale.  This  makes  the  supply  chain  more 
attuned  to  the  strengths  of  balancing  market  forces.) 

4The  U.  S.  movie  industry:  This  sector  had  several  attractive  features.  It  was  more 
profitable  than  other  sectors;  it  mixed  culture  and  business  in  an  apparently 
leveragable  way;  and  its  vertical  integration  extended  to  the  customer,  japan 
knew  that  it  had  to  establish  a  new  model,  selling  to  customers  abroad,  and  was 
interested  in  how  the  engagement  of  customers  could  be  engineered. 

Only  the  latter  two  were  publicly  discussed  with  the  occupiers.  General  Mac- 
Arthur,  as  the  military  governor,  facilitated  building  an  infrastructure  based  on 
these  principles.  You  have  to  understand  that  before  the  war, Japan  was  controlled 
by  a  few  powerful  families  in  feudal  organizations,  zaibatsu.  MacArthur  outlawed 
these,  to  be  later  convinced  that  they  should  be  reinvented  as  keiretsu,  vertical  cor¬ 
porations  modeled  after  the  zaibatsu,  but  with  what  he  though  was  the  democra¬ 
tizing,  western  ingredient  of  market  pull.  Deliberate  emulation  of  the  movie 
business  was  the  model  which  convinced  him,  applied  first  to  the  shipbuilding  and 
then  the  automotive  sectors. 


The  principles  they  extracted  from  food  distribution  and  movie  production  ben¬ 
efited  greatly  by  being  abstracted  from  their  originating  domains;  the  process 
formed  the  basis  of  a  set  of  engineering  principles  for  enterprises.  Later,  when  the 
much  refined  principles  were  abstracted  back  by  the  U.  S.  from  Toyota  and  other 
Japanese  automakers,  we  dubbed  the  collected  diverse  principles  lean. 

The  point  we  are  making  here  is  that  the  movie  sector  in  the  past  has  success¬ 
fully  served  as  a  model  for  VE  engineering  principles.  We’ll  note  below  that  the 
movie  industry  changed  since  then.  While  the  U.  S.  lost  its  steel,  machine  tool,  con¬ 
sumer  electronics  and  shipbuilding  industries,  and  took  big  hits  in  the  automotive 
and  semiconductor  sectors,  Hollywood  completely  dominates  its  now  greatly  ex¬ 
panded  domain. 


All  of  this  is  another  story  than  my  point,  but  let  me  sketch  just  one  more  chap¬ 
ter  in  the  Japanese  thread.  Akio  Morita,  the  founder  of  Sony,  was  knowledgeable 
,of,  and  extremely  interested  in  this  history.  He  followed  Hollywood  closely  and 
was  convinced  that  Americans  were  not  aware  of  (what  we  now  call)  the  agility 
principles  that  had  evolved  of  themselves  right  under  their  noses;  also  that  Japa¬ 
nese  restraint  and  circumspection  could  turn  these  into  a  new  generation  of  enter- 
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prise  engineering  principles.  In  The  Japan  that  Can  Say  No,  he  suggested  that  a 
new  handle  for  world  dominance  could  be  contrived. 

Sony  purchased  a  major  Hollywood  studio  in  the  late  eighties,  Columbia,  for 
twice  its  worth,  the  one  most  closely  associated  with  the  High  Concept  Ideas  not¬ 
ed  below.  To  run  it,  they  hired  executives  whose  only  qualification  was  their  asso¬ 
ciation  with  the  technique.  In  announcing  the  acquisition,  he  briefed  the  kisha  club 
(the  exclusive  Japanese  insider  pool),  citing  the  MacArthur  legacy  and  pointing  out 
a  new  model  beyond  lean.  He  presumably  did  the  same  within  keidanran,  the  busi¬ 
ness  association  widely  considered  the  true  power  in  japan.  This  led  to  his  election 
as  chairman. 

Matshusita  Immediately  followed  suit,  buying  MCA/Paramount.  Instead  of  slow 
osmosis  of  concepts  and  philosophy,  they  pushed  harder,  selling  out  at  a  loss  soon 
after.  We  mention  this  in  our  Waterworld  example.  But  that’s  another  story. 

24.3  Hollywood  Evolves 

IHollywood  develops  the  packet-unit  produaion  system,  a  virtual  enterprise  system.  It  depends  on  a  culturally 
based  trust  communicative  shorthand.) 

Meanwhile,  back  to  the  Hollywood  of  the  late  thirties.  The  U.  S.  broke  up  the 
movie  enterprises,  based  on  antitrust  concerns.  (This  seems  anachronistic  today, 
comparing  the  then  five  equal  competitors  to,  say  Microsoft.)  Distribution  and  pro¬ 
duction  functions  were  severed,  breaking  the  link  to  the  customer  which  was  well 
understood.  Other  factors  intervened;  it’s  an  interesting  case  study.  The  result  was 
the  evolution  of  the  packet-unit  system.  This  is  one  example  of  what  we’ve  been 
calling  the  VE:  the  prime  identifies  the  market  need,  providing  the  plan,  the  intel¬ 
lectual  property  that  addresses  that  need.  It  also  arranges  financing,  which  in¬ 
cludes  providing  the  highest  capital  items. 

Production  assets,  formerly  owned  by  the  companies,  were  distributed  in  many 
small  companies  which  could  be  quickly  assembled  to  produce  a  film,  the  VE  dis¬ 
solving  immediately  thereafter.  It  took  a  little  while  to  optimize  this  system  to  the 
point  that  it  exists  today,  hugely  successful.  (Americans  spend  more  on  entertain¬ 
ment  than  on  defense  and  education  combined.) 

Novel  ways  of  sharing  risk  (distributing  financing),  managing  liability,  and  ex¬ 
ploring  new  ideas  have  been  developed.  But  what  concerns  us  here  is  the  method 
\vhich  evolved  to  understand  and  deal  with  the  customer  after  the  prior  connec¬ 
tion  was  broken.  It’s  a  much  studied  technique  called  high  concept. 

24.4  High  Concept 

[High  concept  defined  and  proposed  as  an  agility  strategy.) 

The  idea  appeared  in  the  mid-seventies  and  utterly  dominated  the  U.  S.  film  in¬ 
dustry  for  a  while,  and  is  still  dominant.  A  high  concept  film  is  one  which  is  based 
on  a  succinct  and  deep  description  of  the  product,  all  elements  of  the  product  that 
would  be  valued  by  a  customer.  Movie  products  are  complex,  involving  several  ex¬ 
hibition  modes  of  the  film  (theater,  TV,  tape,  both  in  the  U.  S.  and  abroad),  as  well 
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as  associated  music,  book,  toys,  theme  rides,  etc.  High  Concept  is  so  named  be¬ 
cause  it  ties  all  elements  across  these  media  and  all  elements  within  the  product 
(story,  stars  and  such)  into  one  clear  statement  of  philosophy  and  style. 

The  underlying  assumption  is  that  the  customer’s  need  can  be  tersely,  under¬ 
standably  and  logically  characterized,  modeled.  That  understanding,  however 
broad  and  involved,  has  a  simple  core,  which  by  itself  covers  all  the  important  el¬ 
ement  of  the  project.  To  quote  Stephen  Spielberg: 

“1  like  ideas,  especially  movie  ideas,  that  you  can  hold  in  your  hand. 

If  a  person  can  tell  me  the  idea  in  twenty-five  words  or  less,  it’s 

going  to  make  a  pretty  good  movie." 

The  conventional  wisdom  is  that  a  High  Concept  film  is  a  stupid  film,  catering 
to  a  feeble,  lowest  common  denominator.  But  it’s  persuasively  argued  that  this 
isn’t  necessarily  so.  Jurassic  Park  is  no  more  a  high  concept  film  than  Schindler's 
List.  As  we  say,  the  notion  of  high  concept  is  thoroughly  studied  in  film  schools, 
and  consistently  practiced  by  producers,  who  are  organizers  of  the  VE.  It’s  also 
considered  difficult  to  master. 

In  all  these  considerations,  the  primary  purpose  of  the  High  Concept  description 
is  to  guarantee  that  the  movie  (and  associated  stuff)  has  each  stage  of  its  produc¬ 
tion  targeted  to  how  it  can  be  successfully  sold  to  the  public,  meaning  it  has  a  con¬ 
cise  tapestry  of  hooks  for  marketing.  Naturally,  just  being  High  Concept  doesn’t 
guarantee  that  the  film  will  be  good,  or  successful,  just  that  it  has  a  shot  (at  success 
at  least). 

To  repeat:  everyone  in  the  industry  understands  High  Concept  as  a  way  of  mod¬ 
eling  the  customer’s  need/desires,  managing  constraints  and  coordinating  a  coher¬ 
ent,  understandable  response.  Its  considered  a  device  for  marketing,  with  the 
emphasis  on  the  link  between  the  prime  (meaning  the  producer)  and  the  customer. 
It  also  helps  a  prime  understand  its  core  competencies,  and  special  strengths;  the 
kinds  of  films  a  studio  plans  are  often  described  in  High  Concept  terms.  In  other 
words,  it  is  a  description  of  a  strategy  to  reach  customers  in  terras  uncierstandable 
to  the  customers,  which  the  producers  use  to  form  a  profitable  link  with  the  cus¬ 
tomers. 

In  shorthand,  a  High  Concept  description  is  succinct:  Flashdance  was  a  Rocky  for 
Women.  Almost  always  the  description  builds  on  prior  experience,  and  familiarity 
with  the  precedents  is  culturally  necessary  for  membership  in  the  community. 
However,  masters  of  the  High  Concept  develop  the  description  to  an  arbitrarily 
deep  level,  with  specific  tailoring  for  each  of  the  major  disciplines  involved. 

Recently,  in  analyzing  how  a  few  studio  heads  consistently  ripped  off  conglorn- 
erate  investors  buying  the  studios  (including  Sonyl),  High  Concept  has  been  impli¬ 
cated  in  a  different  link,  sort  of  up  the  ownership  food  chain.  It’s  an  interesting 
story;  the  value  of  the  production  house  was  artificially  inflated  by  mastery  of  High 
Concept  techniques. 

'  One  can  clearly  see  a  simple  reflection  of  High  Concept  in  the  current  fad  for 
mission  statements,  which  firms  use  to  describe  themselves  to  their  investors  and 
stockholders.  It’s  small  potatoes  compared  to  how  well  developed  and  fluid  High 
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Concept  is  in  films,  but  the  same  idea.  However,  that  use  of  High  Concept  is  not 
cogent  to  agility. 

Working  with  the  movie  people,  we  think  we  have  helped  uncover  an  unac¬ 
knowledged  but  perhaps  critical  role  of  High  Concept  in  another  link:  the  cultural¬ 
ly-based  relationship  among  the  prime  and  its  subs  in  forming  the  VE.  It’s 
described  here  for  the  first  time. 

24.5  High  Concept  in  Organizing  the  VE 

|We  report  on  how  the  cultural  shorthand  enables  agility.] 


24.5.1  What  It  Does,  How  It  Apparently  Works 

(High  Concept  depends  on  and  feeds  its  cultural  base.) 

All  studios  currently  use  the  packet-unit  system  of  production  which  essentially 
means  that  for  every  picture,  a  new  VE  is  created.  Much  to  the  surprise  of  the  stu¬ 
dio  with  which  we  were  working  we  found  that  the  formation  and  operation  of  the 
VE  was  more  agile  when  a  good  High  Concept  for  the  product  existed. 

When  the  AVE  Focus  Group  created  the  AVE  Reference  Model,  we  paid  particu¬ 
lar  attention  to  the  need  for  a  clear  definition  of  the  opportunity,  the  strategy  an¬ 
ticipated  to  address  the  opportunity,  and  the  ersatz  corporate  culture  of  the  VE. 
Given  this,  we  felt  that  the  scope  and  role  of  each  partner  could  be  teased  out; 
when  the  opportunity  changed,  the  change  in  its  description  can  direct  changes  in 
roles  and  responsibilities  of  each  partner. 

High  Concept  fills  that  role  nicely  as  a  tool  in  building  an  AVE.  The  techniques 
and  institutional  support  which  have  evolved  around  the  High  Concept  idea  in  a 
very  large  industry  might  be  instructive,  and  applicable  to,  say,  our  initial  target 
domain  of  the  defense  aerospace  industry. 

To  recall:  in  a  movie  VE,  it’s  composed  by  dint  of  agents.  Some  are  agents  in  the 
showbiz  sense,  individuals  who  professionally  think  and  negotiate  for  writers,  ac¬ 
tors,  directors  and  sometimes  other  major  participants  like  cinematographers.  La¬ 
bor  unions  are  key  agents,  since  they  provide  and  certify  appropriateness  of,  a 
majority  of  the  participants  to  the  various  companies  involved.  Some  of  the  agen¬ 
cies  are  not  human,  but  are  gathering  mechanisms  where  High  Concept  search  and 
exposure  can  be  accommodated. 

Success  on  a  film,  including  keeping  costs  low,  depends  heavily  on  everyone 
having  the  same  idea  of  the  style  and  purpose  of  the  product.  Partners  are  evalu¬ 
ated  based  on  their  experience  with  and  understanding  of  elements  in  the  High 
Concept.  To  an  astonishing  extent,  the  High  Concept  fiilly  serves  as  a  script  of  sorts 
that  the  agents  can  use  to  quickly  and  competently  stitch  together  scores  of  VEs 
per  year. 

>  We  see  the  High  Concept  statement  as  a  tool  for  binding  to  the  customer  as  a 
result  of  losing  the  institutions  (movlehouses)  that  were  there  In  the  306s.  Similar¬ 
ly,  the  High  Concept  is  a  tool  for  binding  to  temporary  production  assets  in  lieu  of 
the  In-house  production  assets  of  times  gone  by.  So,  It  can  be  seen  as  a  way  of 
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binding  the  various  small  partners  to  the  customer  s  in  the  context  of  the  whole  sys¬ 
tem. 


24.5.2  Connection  to  Lightweight  Contracts 

|High  Concept  is  the  context  for  trust.) 

The  central  feature  of  the  High  Concept  is  a  description  of  style;  High  Concept 
films  themselves  are  dominated  by  style.  In  the  High  Concept  definition  are  ail  the 
cogent  elements  of  the  soft  stuff  both  in  and  behind  the  product.  That  is  to  say 
that  High  Concept  captures  the  feel  of  the  picture  as  part  of  its  product  description. 
Elsewhere,  we  talk  about  a  structural  advantage  the  U.  S.  has  in  building  VEs  in  its 
code-based  contract  law,  and  how  Hollywood  utilizes  that  advantage. 

High  Concept  provides  a  scaffold  around  which  these  lightweight  contracts  can 
be  built.  A  good  contract  is  an  agreement  of  what  the  parties  will  do,  what  they 
intend  to  accomplish.  The  contract’s  primary  value  is  in  recording  the  agreement, 
but  the  agreement  is  eminent.  The  deeper  the  agreement,  the  better  the  VE.  The 
High  Concept  is  both  a  collection  of  concepts  around  which  two  parties  can  agree, 
and  also  a  text  representation  of  what  those  concepts  are. 

Movie  concepts  are  lightweight  because  they  rely  on  the  High  Concept  for  all 
the  hard  to  capture,  soft  part,  add  some  quantitative  stuff  (so  many  carpenters,  so 
many  days...)  and  leave  the  exceptions  largely  to  pre-existing  culturally  based  case 
law  (or  its  equivalent  boilerplate). 


24.5.3  Agents  in  the  Strategy 

(Agents  are  empowered  by  this  shorthand,  agents  keep  the  culture  vital.) 

A  discussion  of  contracts  is  a  discussion  of  trust.  In  building  the  VE,  you  need  to 
identify  the  agents  required  to  build  and  maintain  the  VE  and  determine  what  it 
means  to  trust  them. 

The  way  that  High  Concept  definitions  are  put  together  depends  on  a  notion  of 
who  does  what,  so  the  identification  of  agents  (at  least  types  of  agents)  follows  di¬ 
rectly.  For  instance,  if  a  detailed  High  Concept  for  a  science  fiction  film  (as  part  its 
style)  required  flying  monkeys  you  would  have  one  or  more  special  effects  agents 
to  approach  to  discuss  which  among  differing  processes  best  achieves  the  effect. 
It  would  have  to  be  consonant  with  the  desired  overall  philosophy  (and  their  con¬ 
straints:  time/cost)  and  you'd  have  to  know  who  could  do  it. 

Those  types  of  agents  have  evolved  in  the  system.  They  speafe  High  Concept  as 
a  cultural  attribute.  They  tend  to  be  trusted  in  several  ways: 

^There’s  trust  in  their  integrity,  in  the  sense  of  conforming  to  ethics,  morals  and 
values.  The  penalty  for  breaking  this  trust  is  ostracism.  This  type  of  trust  is  inde¬ 
pendent  of  the  High  Concept  idea  the  way  we’re  using  it.  But  in  interviews,  mem- 
f  bers  of  the  community  spoke  of  these  ethics,  morals  and  values  in  very  much 

High  Concept  terms.  There  was  a  widespread  belief  that  Jewish  religious  and 
social  traditions  provide  a  historical  basis  for  this. 
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^There  s  trust  in  the  a  jility  of  the  agent  :o  get  it,  to  understand  and  internalize 
the  High  Concept,  translating  it  into  the  technical  needs  of  the  agent’s  area  of 
expertise  onto  the  voc  abulary  of  suppliers  of  which  they  are  aware. 

^There’s  trust  that  the  right  supplier,  artist,  or  whoever  has  been  selected  by  the 
agent.  A  poor  experience  with  a  partner  translates  directly  Into  a  negative  for  the 
agent.  This  is  inductive  trust,  while  the  others  are  deductive. 

Agents  can  be  completely  independent  persons  or  companies,  they  can  be  rep¬ 
resentatives  of  one  or  any  potential  performers  (as  in  the  Creative  Artist’s  Agency), 

or  they  can  be  part  of  a  diverse  organization,  such  as  the  Development  Director  of 
Industrial  Light  and  Magic. 

The  point  is  that  trust  is  r’elative,  and  High  Concept  gives  a  calibrating  fore¬ 
ground  against  which  trusted  agents  can  be  evaluated. 
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25  Role  of  Defense  Sponsorship 

jin  this  section  we  tie  ManTech  to  the  key  improvement  in  the  mo/ie  industry  and  make  the  general  case  for 
military  sponsorship.! 


25.1  ManTech,  Movies  and  the  Spruce  Goose 

(ManTech  may  be  responsible  for  the  key  ideas  of  High  Concept  trust  in  the  movie  business.) 

WeVe  discussed  the  movie  industry  as  exemplar  of  one  type  of  AVE.  In  the  first 
installment,  Jeffersonian  ideas  about  federation,  and  Quaker  beliefs  of  trust  and 
consensus  support  an  AVE-based  whaling  industry.  The  meme  gets  established  m 
C3S0  l3w  3nd  is  csrricd  vi3  oil  wildc3tt6rs  to  the  movie  industry,  merging  with  Jew- 
ish  ethics.  Along  the  way,  military  investment  plays  a  supporting,  but  not  pivotal 
role.  This  example  was  published  by  the  Agility  Forum  as  well  as  on  the  web  and 
captured  widespread  attention,  though  the  meme  idea  appeared  to  be  largely 
overlooked. 

In  the  second  chapter,  the  insights  are  as  deep  as  the  finding  of  the  lightweight, 
case-law  based  system  of  trusted  agents  and  agreements.  We  discovered  two  piec¬ 
es  of  information:  the  first  that  the  movie  business  provided  a  primary  template 
for  Japanese  ideas  of  enterprise  engineering  we  now  call  lean,  that  template  em¬ 
powered  through  military  guidance. 

The  second  is  that  the  movie  business  has  evolved  since  then  to  be  rnore  of  a 
virtual  enterprise,  using  what  they  call  a  packet-unit  system  of  assembling  frangi¬ 
ble  supply  chains.  To  provide  a  nexus  around  which  these  supply  chains  can  inte¬ 
grate,  a  highly  evolved  mission  statement:  High  Concept,  is  often  used.  Also  of 
note  is  the  recognition  of  the  importance  of  these  new  ideas  of  agility  and  VEs  by 
some  Japanese  business  visionaries. 

That  story  may  have  an  extraordinary  final  chapter  which  we  were  not  able  to 
verify  in  the  time  allotted.  If  true,  it  can  add  substantial  value  to  the  work  that  has 
been  done.  The  story  is  that  the  original  idea  of  forming  opportunistic,  agile  sup¬ 
ply  chains  was  developed  by  the  Department  of  War  s  Monufocturing  Practices 
Group  at  Dayton,  Ohio  (precursor  to  Air  Force  ManTech).  It  was  done  for  the  ship¬ 
building  industry  during  World  War  11,  in  an  attempt  to  create  an  instant  additional 
capability  where  none  existed  before. 

This  was  during  a  period  when  the  head  of  General  Motors,  acting  as  an  army 
general,  had  gathered  the  Allies’  best  industrial  thinkers  at  (what  is  now)  Wright- 
P3tt6rson  Air  Force  B3S0,  which  3S  in  WWI W3S  the  msnsgement  center  for  wsr 
production.  Some  of  these  thinkers  from  the  maverick  Howard  Hughes'  company 
developed  the  idea  to  support  the  making  of  tens  of  thousands  of  Spruce  Gooses, 
monster  wooden  airplanes  designed  to  replace  submarine-prone  steel  and  con- 
Crete  freighters.  For  uninteresting  reasons,  the  war  department  fought  the  idea  of 
the  product  (while  supporting  the  refinement  of  the  process). 

->  So  after  the  war,  Hughes  turned  again  to  making  movies,  installing  these  same 
^process  innovators  as  heads  of  that  business.  Though  Hughes  were  usually 
second  rate,  his  packet-unit  production  system  kept  them  profitable,  providing  a 
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mature  alternative  to  vertical  integration  which  everyone  in  the  industry  had 
adopted  by  the  70s. 

The  story  is  believable  because  of  the  known  legacy  of  defense  sponsorship  for 
novel  business  and  manufacturing  practices,  including  soft  issues.  This  we  briefly 
survey  below. 

The  work  on  which  we  report  in  this  document  is  sponsored  by  the  U.  S.  Depart¬ 
ment  of  Defense.  We  believe  that  agility  is  a  good  idea,  though  not  an  entirely  new 
one.  After  all,  businesses  have  been  responding  to  change  for  centuries.  So,  why 
would  it  be  necessary  to  supplement  market  forces  with  government  sponsorship? 
Wouldn’t  underlying  tools  for  agility  appear  as  a  matter  of  course? 


Quaker  Communitarianism  US  Whaling 


25.2  Why  Now? 

(Agility  is  a  key  issue  in  defense,  especially  aerospace,  readiness.) 

The  examples  we’ve  given  are  from  the  past.  What  has  changed  now  to  make 
agility  of  more  imminent  concern  to  managers?  The  dynamic  of  interest  is  the  ratio 
of  the  rate  of  change  that  gracefully,  spontaneously  occurs  in  the  business  organi¬ 
zation,  compared  to  the  rate  of  change  of  the  environment.  As  the  latter  grows, 
the  need  for  agility  increases. 

The  ability  of  organizations  to  change,  generally.  Is  not  remarkably  better  than 
in  the  past.  And  for  the  kinds  of  products  that  are  increasingly  of  Interest-high  val- 
fue-added  technology-based  products-lt  could  be  argued  that  change  becomes 
much  more  difficult.  Many  of  today’s  organizations  are  larger;  new  products  re¬ 
quire  more  communication  among  different  disciplines  and  funaions;  and  each 
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discipline’s  tools  and  methods  are  becoming  more  mature,  and  often  less  amena¬ 
ble  to  change. 

But  the  rate  of  change  in  the  environment  is  growing  to  an  ever-increasing 
speed.  The  technology  that  goes  into  produrts,  and  that  which  goes  into  the  pro¬ 
cesses  to  make  them,  is  changing  to  an  increasing  extent.  Competition  has  in¬ 
creased  as  we  have  become  more  of  a  world  market.  The  customer  is  becoming 
more  demanding,  more  educated,  and  more  fickle.  And  finally,  the  rate  at  which 
the  investment  community  re-evaluates  its  position  has  increased. 

All  of  a  sudden,  the  need  for  agility  is  no  longer  a  matter  of  a  few  situations.  The 
majority  of  enterprises  in  many  business  sectors  need  greatly  to  increase  the  abil¬ 
ity  to  change,  simply  as  a  matter  of  survival.  Soft  issues  are  central  to  the  problem 
domain. 

25.3  Why  Government  Support? 

(The  only  way  agility  tools  will  hit  the  general  supply  chain  is  through  third  party  (government)  intervention.] 

The  situation  has  changed  from  one  in  which  agility  was  only  occasionally  im¬ 
portant,  to  one  where  it  is  critical.  This  has  happened  fast,  much  faster  than  the 
support  market  (tools  and  technologies)  has  been  able  to  respond.  The  support 
market,  consisting  of  academic  theorists,  tool  suppliers,  and  consultant  practitio¬ 
ners,  is  what  businesses  depend  upon  to  develop  and  support  new  business  prac¬ 
tices  and  underlying  technology. 

This  support  infrastructure  is  itself  un-agile  and  has  not  been  able  to  respond 
with  adequate  agility  tools. 

The  situation  is  a  natural  for  government  research  attention  which  traditionally 
works  in  areas  which  market  forces  will  not  address.  Especially  appropriate  would 
be  investment  in  the  underlying  scientific  and  engineering  principles  upon  which 
tools  and  techniques  can  be  created.  And  this  is  precisely  the  area  in  which  we  are 
working.  This  government  investment  is  intended  to  help  accelerate  the  develop¬ 
ment  of  market-funded  tools. 

What  would  happen  if  the  government  investment  in  agility  were  not  made?  We 
believe  that  various  large  companies  would  develop  some  agility  tools  anyway,  as 
a  matter  of  survival.  But  because  those  tools  would  comprise  a  competitive  advan¬ 
tage,  they  would  keep  them  for  themselves,  keep  them  closed,  off  the  general  mar¬ 
ket. 

Since  the  resources  of  such  companies  will  be  committed  for  internal  tools,  this 
will  starve  the  open  market  of  the  majority  investment  and  customer  base  it  will 
need  to  reach  critical  mass.  AVE  infrastructure  tools  and  techniques  will  not  appear 
in  the  market.  Therefore,  small  companies  would  not  be  able  to  participate  in  AVEs 
unless  they  were  under  the  sponsorship  of  bigger  firms,  a  most  undesirable  situa¬ 
tion. 

25.4  Necessity  of  Government  Investment 

(Agility  is  one  of  several  key  infrastructure  capabilities  that  are  in  the  national  interest.) 
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There  are  copious  examples  of  this  phenomenon  in  both  business  practices  and 
technology,  in  pension  funding,  in  telephone  infrastructure,  and  in  railroad  tech- 
nology.  In  all  cases,  the  trend  was  toward  closed  solutions,  and  the  government 
gently  intervened.  Today,  we  can  hardly  imagine  the  business  world  without  open¬ 
ness  in  these  areas. 

An  example  of  a  good  case  for  government  investment  is  the  original  plan  for 
SEMATECH.  The  U.  S.  had  gone  from  being  the  major  supplier  of  semiconductors 
in  the  world,  to  about  25%  and  falling.Japanese  firms  were  taking  much  of  the  busi¬ 
ness.  The  keidanran  was  the  main  Japanese  strategist. 

The  reasons  were  in  large  part  because  of  the  high  cost  of  forming  a  large  inte¬ 
grated  enterprise  from  a  diverse  supplier  base.  The  primary  business  of  semicon¬ 
ductor  firms  is  not  the  manufacture  of  silicon  chips,  but  the  manufacture  of 
semiconductor  manufacturing  facilities,  or  fabs.  These  fabs  cost  on  the  order  of  a 
billion  dollars  each  today,  with  the  cost  escalating  drastically. 

The  useful  life  of  a  fab  is  alarmingly  short,  less  than  a  decade,  at  which  point  es¬ 
sentially  everything  original  is  obsolete.  Everything  in  the  fab  is  provided  by  other 
parties,  thousands  of  them,  and  every  fab  is  different,  markedly  so,  from  its  prede¬ 
cessor.  The  business  game  here  is  to  integrate  these  thousands  of  partners  quickly 
and  efficiently  into  a  high-yield  integrated  whole.  Profitability  is  wholly  a  product 
of  timeliness  and  elimination  of  waste. 

Japanese  manufacturers  were  able  to  excel  because  their  monolithic,  vertically- 
integrated  keiretsu  were  able  to  gather  and  lock  in  the  majority  of  suppliers  and 
dictate  integration  standards  to  the  remainder  to  a  single  operation.  It’s  a  crude 
integration  model,  which  results  in  less  innovation,  but  greater  agility  in  the  sense 
of  quickly  and  cheaply  creating  a  new  fab. 

In  the  U.  S.  the  best  suppliers  innovated  constantly,  and  they  sold  to  all  comers. 
But  since  each  customer  had  different  integration  strategies,  substantial  energy 
over  tirne  was  spend  both  on  the  supplier  and  prime  side  in  integrating  instead  of 
innovating.  It  was  an  un-agile  system,  resulting  in  fabs  which  were  not  effective 
learning  organizations.  This  is  at  root  a  soft  problem. 

SEMATECH  (SEmiconductor  MAnufacturingTECHnology)  was  formed  to  address 
this  problem.  Industry  and  the  Department  of  Defense  each  kicked  in  what  so  far 
is  a  billion  dollars  to  address  the  problem  of  creating  an  enterprise  integration 
strategy  that  increased  agility,  allowing  federation  of  processes  and  equipment 
from  an  increasingly  innovative,  competitive  supplier  base. 

The  U.  S.  response  was  one  which  leveraged  the  U.  S.  way  of  doing  business,  re¬ 
lying  on  agility  through  market  forces  (though  the  formation  of  the  consortium 
was  before  the  term  became  used  in  this  context).  Industrial  partners  include  IBM, 
AT&T,  Intel,  Digital  as  well  as  other  high  tech  giants,  and  the  idea  was  to  address 
collectively  what  these  giants  individually  could  not,  even  with  massive  and  other- 
^wise  effective  research  efforts. 

The  Defense  involvement  was  keyed  toward  protecting  the  domestic  supply  of 
a  key  component  of  weapon  systems;  this  threat  was  underscored  by  the  publica¬ 
tion  inJapan  of  The  Japan  that  Can  Say  No  coauthored  incidentally  by  Morita.  That 
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book  described  a  Japan  which  controlled  the  source  of  technology  for  U.  S.  weap¬ 
ons  in  such  a  way  that  U.  S.  access  could  be  denied. 

The  case  for  Defense  investment  and  collective  focus  on  agile  infrastructure  was 
clear  and  uniquely  American.  The  early  progress  coward  that  agenda  at  SEMATECH 
forms  the  basis  of  this  metrics  project. 

25.5  Example  of  a  Bad  Investment 

(But  infrastructure  investments  need  constant,  diligent  management.) 

As  it  happened,  for  a  variety  of  reasons  not  important  here,  SEMATECH  changed 
its  focus  from  the  agile  enterprise  integration  problem  to  more  mundane  and  sim¬ 
pler  efforts  in  standards  and  preserving  the  supplier  base  through  subsidy. 

The  idea  of  an  innovative,  agile  domestic  supplier  base  driven  by,  and  fed  by, 
free  market  forces  has  been  abandoned.  The  semiconductor  firms  (to  whom  na¬ 
tional  defense  is  not  a  business  concern),  were  forced  into  the  Japanese  camp.  To¬ 
day,  each  major  U.  S.  company  has  tight,  multiple  relationships  with  former 
threatening  Japanese  competitors.  The  idea  of  a  domestically-based  strategic  in¬ 
dustry  has  been  lost.  Agility  at  the  basic  level  is  no  longer  on  the  agenda,  yet  the 
taxpayer  Investment  has  doubled. 

25.6  Why  the  Advanced  Research  Projects  Agency? 

|ARPA  has  always  been  the  driver  for  high  risk/high  reward  infrastructure  technologies.) 

This  agency,  over  35  years  old,  alternates  between  being  called  the  DARPA  and 
the  Advanced  Research  Projects  Agency  (ARPA),  depending  on  congressional  guid¬ 
ance.  It  is  an  agency  of  the  Department  of  Defense,  chartered  with  being  the  pre¬ 
mier  center  for  high  risk,  high  payoff  projects  for  defense  needs.  DARPA  is  well 
known  for  its  many  innovations  in  the  area  of  basic  information  science,  with  a  fo¬ 
cus  on  precompetitive  infrastructure. 

DARPA  has  also  dabbled  in  dual-use  and  manufacturing  technologies,  with 
mixed  results.  (DARPA  sponsors  SEMATECH.)  We  believe  that  the  problems  of  agil¬ 
ity,  at  least  the  ones  described  here,  are  matters  of  precompetitive  infrastructure, 
instead  of  being  manufacturing  issues  per  se.  As  long  as  we  adhere  to  the  former, 
we  are  rooted  in  DARPA’s  traditional  charter  and  proven  strengths,  in  this  area, 
they  are  arguably  the  premier  agency  worldwide  in  understanding  and  addressing 
fundamental  issues. 

DARPA  sponsors  the  effort  in  agility  which  Includes  the  metrics  project. 

25.7  Why  Air  Force  ManTech? 

)Air  Force  ManTech  has  a  deep  legacy  in  nianufacturing  infrastructure  generally,  and  agility  issues  specifically.) 

The  Manufacturing  Technolo^  Directorate  (ManTech)  In  Dayton,  Ohio  is  less 
well  known  to  the  general  public,  but  they  have  in  many  ways  an  even  more  inter¬ 
esting  history.  ManTech  is  chartered  with  insuring  that  the  domestic  Aerospace 
Defense  Industrial  Base  has  the  most  modern  underlying  technologies. 
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ManTech’s  legacy  is  truly  impressive.  Their  predecessor  organization  was  creat¬ 
ed  in  1917,  shortly  after  the  outbreak  of  World  War  I.  Although  the  U.  S.  had  de¬ 
veloped  the  first  practical  airplanes,  the  domestic  defense  establishment  had 
ignored  them.  The  U.  S.  had  23  aircraft  at  the  outbreak  of  WWI,  while  the  adver¬ 
saries  had  over  500. 

An  organization  was  set  up  to  manage  the  production  of  all  allied  aircraft  to¬ 
gether  with  the  required  infrastructure.  This  has  to  be  the  mother  of  all  virtual  en¬ 
terprises,  involving  the  coordination  of  international  plants  to  build  a  capability 
which  for  practical  purposes  did  not  exist  at  all. 

Within  eighteen  months,  nearly  30,000  aircraft  had  been  produced!  What  makes 
this  feat  so  much  more  amazing  is  that  the  landing  fields,  logistics,  repair,  and 
training  were  created  from  a  dead  stop.  Often,  this  work  included  massive  projects 
in  physical  infrastructure  for  host  cities-sewage,  roads  and  the  like. 

One  thing  that  made  this  possible  was  the  collaborative  transfer  of  information 
among  partners.  The  most  popular  plane,  the  DH-4,  was  of  British  design,  but  the 
engine  was  designed  in  France  and  the  armaments  in  the  U.  S.  The  coordination  of 
information  on  design,  manufacturing,  and  support  from  diverse  sources  under 
mostly  local  control  required  a  new  science  of  management.  So  they  created  this 
new  management  science,  termed  systems  engineering.  Our  AVE  requirements  for 
new  insights  in  management  continue  very  much  in  this  tradition. 

After  the  war,  Europe’s  military  kept  their  defense  plants  under  government 
control.  We  did  not.  Even  then.  Congress,  without  having  an  industrial  policy  per 
se,  believed  that  defense  strength  was  linked  to  a  free-market  based  industrial 
base.  The  Dayton  center,  renamed  Manufacturing  Methods,  was  chartered  to  as¬ 
sure  that  the  best  underlying  technologies,  especially  in  enterprise  practices,  were 
employed  in  this  industrial  base. 

Even  at  that  time,  there  was  a  recognition  that  in  order  to  have  a  strong  defense 
industrial  base,  complementary  commercial  industries  needed  to  be  robust.  Since 
there  was  no  real  market  for  aircraft,  Dayton  helped  create  one. 

Dayton,  therefore,  engaged  in  three  pilot  projects.  First,  they  heavily  promoted 
airmail,  creating  customer  demand  for  this  service.  Second,  they  developed  the 
idea  of  regularly  scheduled  passenger  service,  as  was  already  customary  with  rail 
service.  But  investors  weren’t  biting.  So  they  operated,  as  a  demonstration,  the 
world’s  first  regular  air  passenger  service:  from  Dayton  to  Washington,  to  Langley, 
Virginia,  and  back.  (Langley  was  the  nation's  aerodynamic  research  center,  later 
birthplace  of  NASA  as  it  migrated  out  of  DARPA.)  The  success  of  this  venture  con¬ 
vinced  investors  and  spawned  today’s  airlines. 

Finally,  they  created  an  annual  showcase  so  aircraft  manufacturers  could  com¬ 
petitively  display  their  latest  innovations.  This,  in  combination  with  a  secure  cus¬ 
tomer  base,  ensured  technical  progress  for  decades  and  served  to  create  an 
industry  culture.  The  event,  much  reinvented,  still  continues  today  as  the  Dayton 
Air  Show,  and  its  popular  successors  continue  in  other  cities. 

So,  although  our  Army  Air  Corp’s  defense  posture  was  poor  at  the  beginning  of 
WW II,  Dayton  was  once  again  able  to  spin  up  a  VE-based  global  manufacturing  en- 


Fetruiry  I5,  1997 


237 


Part  3.  Soft  Modeling 

terprise.  The  numbers  here  are  equally  impressive  in  scale  (about  100,000  aircraft 
domestically,  about  twice  that  worldwide),  but  in  this  case  there  was  a  pre-existing 
base.  Notably,  the  enterprise  was  less  hierarchically  centralized  than  one  would 
imagine  and  depended  heavily  on  peer-to-peer  agile  collaboration. 

To  maintain  a  strong  base  in  postwar  precompetitive  infrastructure,  Dayton 
played  a  leadership  role  in  developing  the  underlying  technologies  for  numerical 
control  of  machine  tools.  Computer  Integrated  Manufacturing  (CIM),  enterprise  in¬ 
tegration,  and  currently  the  Lean  Aircraft  Initiative.  All  of  the  predecessor  work 
was  conducted  under  either  their  or  DARPA's  sponsorship,  usually  both. 

ManTech  manages  the  effort  reported  herein,  the  AVE  Metrics  project. 
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26  The  Soft  Modeling/Soft  Mathematics  Problem  Stated 

|Our  beginning  of  an  agenda  of  soft  math  needs  to  be  continued.  The  agenda  is  outlined  in  this  section.] 

The  soft  part  of  the  problem  has  several  dimensions: 

4The  laws  of  Cartesian  logic,  on  which  current  modeling  is  based  are  just  simply 
inadequate  to  model  dynamics  of  the  social  and  cultural  infrastructure.  This  is 
widely  recognized  (DEVL971,  and  there  is  now  almost  a  stampede  to  explain  the 
collapse  of  artificial  intelligence  in  these  terms.  At  the  same  time,  the  key  role 
that  those  social  and  cultural  effects  play  cannot  be  ignored. 

But  it  is  also  true  that: 

^We  need  to  have  a  model  of  the  threat  to  the  system,  the  behavior  to  which  we 
are  responding.  It's  not  widely  recognized  that  this  is  necessary,  since  most  mod¬ 
eling  is  done  in  a  static  context,  where  external  behavior  can  be  essentially 
defined  as  boundary  conditions.  But  dynamic  modeling  requires  a  specific  model 
of  the  dynamic  environment. 

But  agility  is  by  definition  the  ability  to  respond  to  unexpected  change.  How  can 
one  model  behavior  that  by  definition  cannot  be  modeled?  This  requires  soft 
modeling. 

^The  kinds  of  enterprises  that  are  of  interest  are  huge,  complex  and  wildly 
diverse.  We  seek  to  understand  agility  which  is  driven  by  a  very  few  factors,  but 
which  Is  a  system-level  phenomenon.  Conventional  techniques  would  demand 
that  most  of  the  system  be  modeled,  but  that  is  unrealistic  for  us.  We've  devised 
a  trick  to  decompose  types  of  dynamics  via  infrastructures  that  gets  around  this 
problem  temporarily. 

But  we  lose  the  ability  to  get  a  handle  on  important  system-level  agility  dynamics 
such  as  second  order  agility.  A  soft  modeling  ability  is  needed,  to  allow  us  to  cap¬ 
ture  important  features  of  the  context  of  the  enterprise,  zooming  in  and  out  as 
required. 

There  are  also  probably  families  of  novel  analysis  that  soft  mathematics  could 
support.  Trust  is  an  example  of  one  such  family. 

26.1  Three  Possible  Approaches 

(We  examined  conventional  social  science,  a  new  trend  in  epidemiology,  and  Situation  Theory.  The  first  is  inad¬ 
equate.) 

The  metrics  are  upstream  metric).  This  means  that  we  must  have  a  formal  model 
of  the  real  processes  at  work.  We  then  find  the  few  features  in  those  processes  that 
affect  agility  and  derive  the  information  we  need.  This  is  an  entirely  different  pro¬ 
cess  than  mere  benchmarking,  which  asks  questions  only  about  the  current  state 
of  the  enterprise.  We  measure  capability,  so  we  need  access  to  actual  processes. 

^  The  first  stage  of  the  metrics  is  in  the  domain  where  we  have  explicit  descrip¬ 
tions  of  the  processes  already  extant.  We  have  models,  or  can  easily  create  models 
of  workflow  processes,  business  processes,  and  contracts  and  regulations.  We  are 


Fttruary  15,  1997 


239 


Part  3,  Soft  Modeling 


mean  something  in 
a  context 


Within  the  AVE,  most 
of  the  high  value  pro¬ 
cesses  are  social  and 
cultural,  that  is,  soft 
This  was  the  driving 
requirement. 


Agility  only  requires 
that  a  small  number 
of  key  processes 
be  considered,  but 
considered  as  their 
coupling  to  the 
whole. 


Figure  26-1  Three  Needs  for  Softness 

not  so  blessed  in  the  cultural/social  domain.  The  activities  here  are  complex,  im¬ 
plicit,  and  not  well  understood. 

To  make  matters  worse,  there  is  controversy  about  how  best  to  characterize 
what  can  be  made  explicit  about  these  processes.  A  first  order  of  work  for  us  in  the 
social/cultural  context  was  to  decide  which  one  of  the  competing  paradigms  has 
value  for  us.  The  three  paradigms  are:  ordinary  social  science,  an  epidemiology- 
based  view,  and  situation  theory.  We  have  chosen  the  latter. 

The  default  is  social  science,  which  we  chose  not  to  follow,  was  to  pursue  the 
conventional  approach  based  on  sociology,  psychology,  and  anthropology.  It’s  a 
robust  area  of  work  that  has  produced  most  of  the  existing  insights  we  have  into 
the  organizational  dynamics  of  VEs. 

The  approach  used  is  reasonable.  Coarsely  characterized,  it  consists  of  large 
numbers  of  observations,  from  which  theories  are  created  and  then  tested  by  ex- 
periment-more  or  less,  the  scientific  method.  But  these  theories  are  theories  of 
behavior,  and  not  of  the  underlying  physics. 

For  example,  one  would  look  at  successful  enterprises  and  notice  that  they  tend 
to  have  a  more  empowered  workforce.  Since  the  correlation  is  high,  one  would  the¬ 
orize  that  such  empowerment  causes  (or  contributes  to)  success.  The  correlation 
Is  essentially  a  statistical  one,  which  does  not  provide  a  well-understood  model  of 
exactly  what  is  going  on  in  a  real  causal  sense:  for  instance,  what  varieties  of  em- 
ipowerment  change  the  organization  in  what  respects  to  result  (perhaps  through 
many  chained  processes)  in  what  particular  kinds  of  success. 
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Much  of  the  work  in  agility--and  indeed  also  in  lean  and  other  management  ap- 
proaches~is  of  this  anecdotal  correlation  type.  That  certainly  has  value  for  many 
uses,  but  not  for  our  target  use:  high  confidence  metrics  that  can  be  used  to  engi¬ 
neer  the  VE  for  agility.  In  order  to  engineer  something,  you  have  to  know  how  it 
works. 

An  analogy:  for  years,  a  connection  between  aluminum  in  the  brain  and  Alzhe¬ 
imer's  disease  has  been  clear  from  a  statistically  correlated  perspective.  The  corre¬ 
lation  is  clear,  but  since  we  do  not  understand  the  mechanism  involved,  we  cannot 
say,  even  tentatively,  for  example,  that  people  should  stop  drinking  soda  from  alu¬ 
minum  cans.  Such  a  temptation  is  great,  but  we  simply  do  not  yet  understand  the 
underlying  mechanics  sufficiently  to  engineer  a  response. 

Medical  literature  is  full  of  observations  like  this,  wiilch  often  give  rise  to  super¬ 
ficial  or  speculative  arguments  about  the  validity  of  the  statistical  correlation:  Does 
proximity  to  power  lines  cause  cancer  in  Swedish  schoolchildren?  Does  eating  yo¬ 
gurt  cause  breast  cancer?  A  recent  study  actually,  incorrectly  as  it  turned  out,  sug¬ 
gested  this. 

Even  in  cases  where  the  correlation  is  clearly  causal-smoking  and  lung  cancer 
or  aspirin  and  headache  abatement-the  underlying  laws  are  what  really  offer  the 
most  potential. 

This  Is  important  in  the  present  context  because  agility  is  a  whole  new  animal. 
The  temptation  is  to  revert  back  to  conventional  actions-flat,  empowered  organi¬ 
zations,  lean  work-in-progress,  reduced,  prequalified  supplier  base-and  somehow 
to  make  a  correlation  between  ail  that  and  agility. 

But  our  case  base  in  the  context  of  agility  is  too  small  and  too  poorly  understood 
to  make  a  smoking-to-cancer  causal  link.  Our  understanding  of  how  social  and  cul¬ 
tural  dynamics  work,  even  outside  the  context  of  agility,  Is  poor.  Furthermore, 
agility  Involves  such  a  range  of  novelty  that  part  of  the  nature  of  agility  will  always 
be,  by  definition,  outside  the  available  case  base.  But  this  could  change. 

So  while  we  believe  ordinary,  conventional  soft,  social  science  contributes 
much,  including  indicators  for  further  examination,  we  simply  cannot  use  it  as  a 
basis  for  metrics.  Statistical  correlations  without  a  formal  model  of  the  processes 
is  Insufficient. 

26.2  Epidemiology  and  the  Organizational  Imperative 

[There  is  an  interesting,  well  funded  trend  in  epidemiology,  but  it  misses  satisfying  our  rigorous  criteria.) 

Much  of  epidemiology  follows  the  same  model  we  just  discussed.  But  epidemi¬ 
ology  is  the  study  of  the  cause  as  well  as  the  spread  of  disease.  It’s  a  prospective 
science.  So  this  requires  use  of  statistics  as  an  indicator  of  symptoms,  but  also  in¬ 
dicates  a  need  to  dig  deeper. 

What  attracted  us  to  look  at  epidemiology  in  the  first  place  was  the  introduction 
of  social  modeling  into  epidemiology  from  its  origins  in  the  days  of  Yellow  Fever 
and  Malaria.  Researchers  need  to  model  the  dynamics  of  the  vector  of  the  disease 
at  the  process  level.  For  instance,  they  would  take  into  account  how  fast  mosqui- 
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toes  breed,  how  far  they  fly,  what  mechanism  attracts  them  to  humans  (which  will 
involve  other  models  of  wind  and  what  foods  the  people  eat),  and  so,  on  into  quite 
a  bit  of  detail.  (Incidentally,  this  Yellow  Fever  case  study  which  corresponds  to  the 
building  of  the  Panama  Canal  by  the  French  and  then  the  U.  S.  led  to  the  French/ 
British  cultural  meme  insight). 

But  the  important  observation  for  us  is  that  they  must  also  model  the  social  ac¬ 
tions  that  promote  or  fight  the  spread  of  the  disease.  So  they  might  model  the  de¬ 
gree  of  corruption  or  laziness  of  mosquito  prevention  inspectors,  or  the  tendency 
of  the  local  population  to  cooperate  and  learn  certain  preventive  measures.  Such 
factors  were  key  to  modeling  Yellow  Fever  in  Panama,  and  social  factors  are  cer¬ 
tainly  relevant  to  modeling  the  dynamics  of  AIDS. 

So  we  find  here  several  attractive  ideas,  whose  effects  are  amplified  by  the  very 
large  research  budget  of  the  National  Institutes  of  Health  spent  on  such  modeling, 
compared  to  the  relative  paucity  of  manufacturing  and  commerce  systems.  One  of 
these  ideas  is  the  deliberate  mixing  of  models  that  are  deterministic  with  those 
that  are  statistical. 

In  fact,  the  discipline  seems  to  be  pushing  the  limits  of  conventional  statistical 
analysis  to  include  several  layers:  the  layer,  for  instance,  that  captures  the  likeli¬ 
hood  of  a  person  being  in  a  high  mosquito-breeding  area,  which  is  empirically  de¬ 
termined,  and  the  likelihood  that  this  person  has  learned  how  to  avoid  getting 
bitten,  an  approach  which  combines  some  mechanisms  with  probabilities. 

Another  compelling  idea  from  epidemiology  is  the  inclusion  into  the  vector  of 
consciousness  as  a  collective,  and  acting  as  an  intelligent  agent.  Thus,  the  collec¬ 
tion  of  malarial  parasites  does  what  it  has  to  do  to  ensure  its  survival  and  spread, 
actions  such  as  preserving  the  hosts  and  inducing  sweating,  which  attracts  more* 
mosquitoes.  It’s  a  particularly  powerful  idea  when  one  wants  to  consider  how  the 
organization  learns;  in  this  case,  it  would  be  how  agility  agents  or  memes  evolve 
to  its  advantage  in  response  to  change. 

When  the  idea  is  extended  to  social  action,  it  generates  particular  insights.  So, 
instead  of  just  understanding  an  organization  as  an  entity,  we  could  understand 
particular  ideas  and  other  phenomena  as  entities  themselves.  An  idea,  for  instance, 
the  idea  of  guaranteed  job  security,  takes  on  a  life  of  its  own,  adapting  in  how  it 
manifests  and  is  handled  by  its  hosts,  in  order  to  survive. 

We  mentioned  something  of  this  sort  in  the  whaling  example.  When  the  indus¬ 
try  spawned  the  petroleum  business,  certain  key  ideas  had  to  adapt  in  order  to  sur¬ 
vive.  We  noted  that  one  suggestion  was  that  these  ideas  chose  Rockefeller,  instead 
of  the  conventional  view,  that  a  great  man  shaped  the  industry  after  his  own  ideas. 

The  project’s  advisors,  the  AVE  Focus  Group,  found  this  way  of  thinking  to  be 
useful  for  generating  some  insights  and  worthy  of  exploration  and  development. 
But  we  felt  that  the  whole  way  of  thinking  strays  too  far  away  from  managers’ 
^needs  to  generate  some  model  science  worth  leveraging  for  the  project.  We  in¬ 
stead  invested  in  Situation  Theory. 
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27  Situation  Theory 

[Situation  Theory  is  introduced  in  this  section.) 

We  have  chosen,  instead,  to  develop  the  ideas  of  Situation  Theory  as  a  basis  for 
the  modeling  science  for  our  metrics,  the  version  of  those  metrics  that  extends  the 
scope  into  social  and  cultural  phenomenon. 

Situation  Theory  is  based  on  a  few  powerful  ideas.  A  popular  exposition  of  Sit¬ 
uation  Theory  can  be  found  in  (DEVL91]with  technical  details  in|BARW881.  One 
major  idea  on  which  Situation  Theory  is  based  is  to  separate  the  structure  of  the 
base  case,  the  object  phenomenon  (often  based  in  the  real  world),  from  the  ana¬ 
lytical  domain  in  which  it  is  analyzed. 

For  example,  two  well-acquainted  machinists  having  a  conversation  about  their 
work  make  certain  presumptions  for  economy  and  conciseness.  A  non-machinist 
observer  happening  upon  the  scene  might  have  trouble  understanding  what  they 
say.  Some  aspects  of  this  particular  situation  developed  over  the  long  term,  com¬ 
ing  from  special  machinist  terms  they  use,  as  well  as  from  conversational  conven¬ 
tions  iDased  on  their  long  association  together,  and  some  aspects  are  temporary, 
referring  to  what  just  happened  before  the  observer  arrived. 

The  idea  here  is  to  use  a  different  set  of  rules  and  logic  in  characterizing  the  im¬ 
plicit  meaning,  that  the  observer  missed,  from  the  rules  used  in  the  conversation. 
The  latter  constitutes  the  situation  in  which  the  conversation  was  being  held. 

It  seerns  logical  that  we  distinguish  between  these  two.  It’s  not  as  if  we’re  mak¬ 
ing  the  distinction  between  the  discipline  of  machining  and  listening,  but  of  listen¬ 
ing  circumspectly  and  thinking  circumspectly  about  listening.  The  former  Is  to 
some  extent  a  result  of  fixed  laws  of  physics  and  psychology,  while  the  latter  Is  not 
and  is  theoretically  open  to  a  wider  range  of  abstract  mathematical  tools.  Howev¬ 
er,  the  temptation  to  carry  basic  axiomatic  content  from  the  former  to  the  latter  is 
great. 

Situation  Theory  makes  clear  the  distinction  between  the  two,  by  enforcing  the 
view  of  a  situation  as  a  context  for  eveiy  action  by  an  agent.  This  view  of  the  agent 
is  consistent  with  our  use  of  It  elsewhere);  an  agent  is  a  discrete,  self-aware  entity 
with  the  power  to  Influence  other  agents.  The  context  encompasses  of  a  number 
of  aspects,  some  of  which  (like  types  and  relations)  have  formal  meaning  only  in 
the  analytical  domain. 

27.1  Situation  Theory  in  Linguistics 

[The  theory  originated  in  the  study  of  language  and  communication.) 

Situation  Theory  emerged  about  1 5  years  ago  in  response  to  a  set  of  problems 
in  linguistics:  how  best  to  build  a  formal  model  of  information  to  describe  commu¬ 
nication.  An  agent,  then,  will  extract  information  from  the  environment,  much  of 
which  was  not  communicated  in  any  explicit  language,  but  which,  nonetheless, 
\vas  understood  nonetheless  as  if  it  had  been  communicated.  That  agent  may  then 
communicate  to  another  agent  some  information,  conveyed  by  conventional  lan- 
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guage,  and  some  further  information,  convened  by  characterizing  the  inheritance 
of  the  situation. 

So  a  study  of  language  is  a  study  of  communi  :ai:ion,  and  that  in  turn  is  a  study 
in  information.  And  a  key  component  in  the  study  of  information  is  a  formal  ap¬ 
proach  to  this  idea  of  how  t  he  agent  is  situat  ed.  There  has  been  a  fair  amount  of 
work  toward  developing  such  a  theory,  with  a  predictably  formal,  specific,  and 
sometimes  abstruse  collection  of  concepts  and  terms. 

Individuals,  relations,  spat/a/  pjacement,  temporal  placement,  situations,  types, 
and  parameters  are  the  stuff  of  Situation  Theory.  These  factors  are  used  in  devel¬ 
oping  ideas  about  how  an  entity  individuates,  which  sets  certain  characteristics 
about  the  potential  for  information  transfer.  The  unit  which  is  transferred  is 
known  as  an  infon. 

One  can  already  see,  we  hope,  that  Situation  Theory  goes  far  in  clearing  the 
slate  and  building  a  new  basis  for  information  about  information,  while  being  care¬ 
ful  to  inherit  few  of  the  mathematical  assumptions  which  govern  the  milieu  of  the 
source  information. 

27.2  Ontology 

[One  major  result  has  spun  out  of  the  theoretical  work.) 

The  rnanufacturing  enterprise  is  typical  of  many  human  enterprises  in  that  its 
foundation  resides  In  communication,  information  transfer.  It  is  atypical  of  much 
human  endeavor  because  we  try  to  organize,  engineer,  and  optimize  the  enter¬ 
prise  toward  specific  goals.  Therefore,  we  have  always  had  two,  often  overlapping, 
classes  of  people  in  the  enterprise,  those  who  do  the  work  and  those  who  try  to’ 
understand  and  manage  the  work. 

The  primary  tool  of  the  second  group  is  the  model,  broadly  used  here  to  mean 
a  representation  of  what  goes  on.  Modern  enterprises,  at  least  many  interesting 
ones,  use  a  large  number  of  models  and  their  associated  methods  to  look  at  the 
enterprise’s  parts,  viewed  a  number  of  different  ways.  So,  much  of  the  research 
currently  conducted  Is  oriented  toward  understanding,  extending,  and  refining  the 
art  of  modeling. 

A  key  issue  now  being  addressed,  by  Department  of  Defense  (ManTech  and  DAR- 
PA)  sponsored  model  researchers  and  others,  is  the  issue  of  ontology.  It’s  con¬ 
cerned  with  the  formal  specification  of  the  elements  of  the  model,  so  is  very  much 
in  the  scope  addressed  by  ST.  It  comes  as  no  surprise  that  the  manufacturing  mod¬ 
eling  community  Is  beginning  to  find  Situation  Theory  particularly  useful  in  creat¬ 
ing  enterprise  ontologies. 

Here's  a  simple  explanation  of what  an  ontology  is:  suppose  you  had  two  people 
that  had  similar  backgrounds  and  they  wanted  to  talk.  Well,  they'd  have  little  trou¬ 
ble  communicating.  But  suppose  they  both  spoke  the  same  language  but  came 
Trom  radically  different  cultural  and  religious  perspectives.  The  basic  worlds  that 
they  live  in  could  be  so  different  that  they  could  have  little  meaningful  conversa¬ 
tion,  one  could  imagine. 
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But  suppose  you  introduced  a  third  person,  a  translator;  not  a  language  transla¬ 
tor  since  they  both  speak  the  same  language,  but  a  concept  translator. 

“When  he  says  here  (or  causes  or  seems  or  Joues,  for  example), 
what  he  means  in  your  terms  is..." 

An  ontology  is  a  statement  of  all  such  relevant  terms  and  mechanics  of  a  partic¬ 
ular  world  such  that  someone  who  speaks  the  language  of  the  ontology  (usually 
simple  logic)  can  understand  events  and  descriptions  of  events  in  that  world.  It's 
easy  to  see  that  ontologies  are  a  major  need  in  artificial  intelligence  when  two 
knowledge  representation  systems  need  to  share  knowledge.  The  business  enter¬ 
prise  needs  ontologies  when  many  models  are  combined,  translated  or  federated. 

The  one  solid  practical  result  of  Situation  Theory  to  date  is  as  a  formal  basis  for 
knowledge  representation  ontologies  where  the  difference  between  the  systems 
is  known  and  implicit.  It  has  only  experimentally  been  extended  into  the  areas 
where  the  differences  are  not  well  explicated  and  the  difference  in  worldviews  is 
cultural  (DR96j. 
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28  A  Situation  Theory  Primer 

jWe  begin  an  elementary  ovemew  of  Situation  Theory  for  our  purposes.) 

This  section  gives  a  brief,  simple  overview  of  Situation  Theory  for  the  purposes 
of  BAST.  More  complete  introductions  are  in  |DR96|  (DEVL911  (BARW88J. 

Situation  Theory  is  novel  in  that  it  introduces  a  notion  of  situation  as  a  first  class 
object  into  equations  that  behave  as  logical  statements.  The  trick  is  that  a  situation 
is  a  largely  unknown  blob  of  facts,  in  other  words  it  is  a  soft  object,  one  whose  in¬ 
ternals  haven't  been  made  explicit.  These  statements  are  usually  of  the  form: 

8^=01,  G2,... 

or 

S  t=  <the  specification  of  an  infon>,... 

where  S  on  the  left  stands  here  for  a  situation,  and  the  items  on  the  right,  which 
can  be  numerous,  are  some  facts,  pieces  of  information  about  the  situation  which 
are  known  as  infons.  The  symbol  that  looks  like  an  equals  sign  with  a  vertical  line, 
adopted  from  Tarski,  means  supported  by,  or  more  specifically  that  the  fact  on  the 
right  is  true  in  the  situation  on  the  left. 

So  the  equation  means  that  the  situation  S,  which  may  be  your  situation  is  sup¬ 
ported  by  the  infons  on  the  right,  which  might  be  true  statements  about  the 
weather  outside  your  window.  We  don't  know  much  about  your  situation  at  the 
moment,  but  we  do  know  a  few  things  at  least  about  its  weather.  We've  made 
some  hard,  explicit  statements  on  the  right  about  the  dominantly  so/it  thing  on  the 
left. 

28.1  Infons 

jinfons  are  statements  of  fact»  the  hard  stuff.) 

The  items  on  the  right  are  infons,  statements  of  fact.  Infons  articulate  things 
about  situations,  in  fact  are  the  only  way  to  articulate  hard  things  about  situations, 
so  it's  no  surprise  that  they  have  a  carefully  designed  internal  structure.  If  the  infon 
is  in  its  usual  form  of  a  collection  of  items  which  states  the  fact,  the  form  is  as 
shown.  The  first  item  is  a  characterizer,  a  name  for  the  fact,  describing  the  action 
or  characteristic  involved.  This  is  followed  by  one  or  more  variables  pertaining  to 
the  infon  (more  about  those  later),  and  the  last  entry  is  a  truth  value  of  1  or  0. 

S  \=  «(a  relation),  (a  number  of  things  about  the  relation),  (a  “truth” 
value)» 

S  1=  «speaks,  HTG,  [here],  [now],  1»  has  Ted  speaking  now 
S  «sits,  HTG,  [here],  [now],  0»  has  Ted  not  sitting  now 


If  the  truth  value  is  one  the  positive  state  is  meant;  this  is  the  straightforward 
meaning  of  the  fact  is  true  in  the  situation.  But  as  informative  is  the  negation,  when 
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the  value  is  zero:  it  is  true  in  the  situation  that  the  fact  is  not  supported.  (Another 
form  of  negation  is  in  the  supports  relationship.  In  this  case,  the  situation  does  not 
support  the  fact  denoted  by  the  infon,  not  the  same  as  infon  negation). 

T  N  «freezes,  [August],  0»This  infon  supports  the  situation  in  Tustin,  CA 
P  N  «freezes,  [August],  1»This  infon  supports  the  situation  in  Perth 
P  ^  «freezes,  [August],  0»This  infon  does  not  support  the  situation  in 


The  truth  values  support  logical  operations  over  infons,  providing  the  basis  for 
importing  all  sorts  of  existing  logical  tools  to  reason  about  situations. 

The  internal  entities  denote  temporal  and  spatial  locations.  Individuals,  param¬ 
eters  (meaning  indeterminants),  and  other  situations.  Also  in  here  are  types  which 
we  discuss  below.  Substantial  effort  In  defining  these  entities  has  rewarded  work¬ 
ers  with  a  clean,  computable  way  of  reasoning  about  situations  and  contexts.  In¬ 
deed,  the  foundation  for  defining  and  managing  ontologies  comes  from  this  area. 
For  our  purposes,  it's  not  essential  to  describe  these  entities. 

28.2  Types 

ITypes  can  be  not  over  conventional  (hard)  items,  but  soft  situations  as  well.] 

Each  of  the  objects  in  an  infon  can  belong  to  a  higher  order  type,  usually  ab¬ 
stracted.  The  basic  types  are  abstracted  from  the  entitles  we  described  as  consti¬ 
tuting  and  infon,  but  there  are  also  situation  types  which  have  some  different 
properties  because  of  the  softness  of  situations. 

One  can  investigate  what  types  of  hard  stuff  characterizes  and  constrains  situa¬ 
tions;  indeed,  this  is  the  primary  tool  we  want  to  explore  In  engineering  situations. 
(Of  course,  in  the  AVE  context  situation  is  used  in  its  ordinary,  simple  meaning.) 
Since  infons  have  a  behavior  as  information,  moving  around  and  changing  their  en¬ 
vironment,  one  can  also  develop  a  theory  of  types  that  reasons  about  the  commu¬ 
nication  channels  they  follow. 

All  of  this  emerged  later  in  the  theoiys  life.  It  evolved  from  strongly  set  theoretic 
ideas  of  logic  and  has  migrated  into  basic  mechanics  of  information  abstraction 
and  aggregation  which  are  better  suited  to  category  theory.  Recognition  of  that 
fact,  at  least  so  far  as  our  AVE  Interest  Is  concerned  was  a  result  of  BAST. 
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29  Physics  and  Behavior  for  BAST96 

[This  section  introduces  the  issues  of  the  first  Business  Applications  of  Situation  Theory  workshop.) 

This  section  touches  on  a  few  of  the  issues,  desiderata,  and  possible  founda¬ 
tions  of  this  new  soft  mathematics.  The  requirements  and  insights  come  from  a 
study  of  social  and  cultural  dynamics  within  the  design  of  highly  opportunistic, 
flexible,  temporary  associations  of  individuals  and  small  groups  that  come  togeth¬ 
er  to  act  as  a  coordinated  unit,  Agile  Virtual  Enterprises. 

When  working  with  a  phenomenon,  one  needs  to  have  sufficient  knowledge 
about  how  it  works.  More  information  than  the  minimum  that  suffices  may  be  ir¬ 
relevant  for  a  particular  use.  We  can  assume  that  any  system  has  a  logic,  using  the 
term  in  its  broad  sense  to  mean  the  understandable  laws  that  drive  its  behavior. 
The  logic  of  many  natural  systems  is,  presumably,  bottomless:  that  is,  the  more  we 
study  the  system,  the  more  of  its  logic  we  find  remains  to  be  revealed.  We  can  nev¬ 
er  fully  understand  the  logic  of  many  such  systems. 

What  we  have,  instead,  is  information  about  the  system's  behavior.  As  the  logic 
is  better  understood,  more  information  becomes  available  to  us.  The  scientific 
drive  is  to  develop  more  insight  about  a  system's  logic.  But  it  is  the  job  of  the  en¬ 
gineer  to  work  with  the  information  at  hand. 

For  instance,  we  still  have  no  deep  understanding  about  the  physics  of  gravity, 
its  deep  logic-,  but  we  have  a  great  deal  of  Information  about  its  behavior.  That  in¬ 
formation  is  sufficiently  useful  to  allow  engineers  to  make  reliable  and  precise  pre¬ 
dictions  about  how  certain  gravitational  systems  will  behave  in  the  future. 
Meanwhile,  scientists  pursue  the  graviton. 

The  logic  of  a  social  system's  physics  and  the  information  we  have  about  its  be¬ 
havior  appear  to  have  quite  a  complex  relationship.  The  relationship  is  more  com- 
plex-and  knowledge  about  the  behavior  is  more  useful-than  might  be  implied  by 
dismissive  characterizations  of  behavior  as  merely  a  more  abstract  or  less  accurate 
approximation  of  physics.  (It  could  be  that  behavior  doesn't  get  enough  respect.) 
Physics  is  to  behavior  as  logic  is  to  information.  If  we  can  use  certain  information 
to  ascertain  some  of  its  underlying  logic,  then  we  should  be  able  to  work  with  an 
appropriate  array  of  behavior  in  order  to  understand  at  least  some  of  its  physics. 
This  issue  has  become  Important  to  our  present  studies  in  agility.  We  want  to  be 
able  to  look  at  a  system  and  evaluate  how  adaptable  it  is,  how  easily  its  actors  can 
learn. 

We  have  a  promising  technique  (for  measuring  the  adaptability  of  systems)  that 
looks  at  representations  of  processes  which  we  require  to  be  representations  of 
very  basic  behavior  in  the  system,  behavior  that  reveals  basic  logic  about  the  sys¬ 
tem's  physics.  Then,  some  analysis  about  the  logic  of  the  representation  (or  meta¬ 
logic  about  the  behavior)  tells  us  how  adaptable  the  processes  are  likely  to  be.  We 
could,  then,  better  predict  beha\dor. 

,  But  the  approach  depends  on  the  behavior  which  is  modeled  revealing  the  sys¬ 
tem's  physics.  That  the  modeled  behavior  reveals  logic  is  a  workable  assumption 
when  the  physics  of  the  system  is  artificial  (human-made).  Business  rules  exhibit 
an  artificial  physics:  the  physics  itself  is  defined  by  a  set  of  explicit  rules.  We  don't 
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ordinarily  have  to  perform  scientific  experiments  to  discover  who  is  the  boss  of 
whom  or  who  has  engineering  responsibility  for  a  product.  Usually,  such  things  are 
explicitly  (and  reliably)  stated;  the  physics  results  from  the  information.  ^ 

Contract  laws  and  regulations  form  a  domain  that  Is  less  well-behaved  than  busl- 
™  deterministic-reasonable  people  can  disagree  over  respon- 

sibilities  in  peculiar  situations.  And  what  is  true  has  the  additional  burden  of  being 
admipible  within  the  system.  But  the  physics  of  the  domain  still  comes  from  ex¬ 
plicitly-represented  information. 

We  also  look  at  physical  processes,  for  Instance,  the  scheduling  and  sequencing 
of  processes  to  assemble  a  device.  Here,  the  laws  of  nature  bear,  but  for  all  prac- 
tical  purposes  of  this  domain,  they  are  fully  known  all  the  way  down  to  a  given 
base:  Newtonian  physics. 


But  a  great  many  of  the  processes— it  seems,  the  most  important  processes— that 
bear  on  an  enterprise  are  human  forces,  social,  and  cultural  interactions.  In  these 
domains,  the  relationship  between  physics  and  behavior,  as  well  as  the  relation¬ 
ship  between  logic  and  information,  becomes  quite  significant.  In  these  social  cas¬ 
es,  there  are  scant  engineering  principles.  Dealing  In  these  domains  so  far  has 
remained  more  an  art  than  a  science. 


But  many  of  us  would  like  to  make  better  decisions  about  enterprises,  to  make 
them  better  in  terms  of  human  sensibility.  After  all,  if  collaborating  workers  aren't 
really  motivated  to  participate,  the  enterprise  cannot  possibly  work  optimally.  Un¬ 
informed  decisions  can  end  up  creating  the  sort  of  organizations  we  want  to  avoid- 
those  which  are  brittle,  unlikely  to  adapt,  and  unrewarding  places  to  work. 


29.1  Information  Foreground  and  Background 

iSituation  Theory  currently  covers  background  information.  We  need  it  to  handle  the  dirert  information  of  the 
communication  in  the  same,  soft  manner.) 

This  problem  Is  not  trivial:  namely,  the  application  of  mathematics  to  human  in¬ 
teraction.  It  may  be  our  foremost  problem  in  re-examining  the  foundations  of  in¬ 
formation  science.  Our  subset  of  that  grand  challenge  is  whether  we  can  come  to 
a  better  understanding  of  information  in  these  interactions  to  help  enlighten  us 
about  their  logic  (or  laws  or  mathematics  or  physics,  if  you  prefer). 

A  decade  of  so  ago,  we  took  a  giant  step  forward  in  addressing  the  problem.  In 
sinjple  systems,  the  information  that  is  conveyed  between  two  entities  is  entirely 
to  be  found  in  the  communication  between  them.  That  has  been  largely  the  case 
in  our  relatively  simple  domains  of  business,  legal,  and  physical  processes.  But  in 
human  communications,  often,  what  Is  conveyed  is  mostly  not  explicitly  found  in 
the  actual  message. 

Often,  much  is  unconsciously  assumed  among  the  parties  about  the  situation. 
Some  of  these  assumptions  are  domain-  or  culture-specific:  Si  spanner  means  one 
►thing  to  a  British  mechanic,  another  to  his  or  her  American  counterpart.  Some  are 
common  knowledge:  a  cake  can  be  put  in  a  box,  but  not  the  other  way  around. 
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Some  are  implicit  inferences,  and  some  seem  to  be  hardwired  into  the  particular 
linguistic  binding  we  undergo  when  young. 

The  advance  in  addressing  these  issues  was  provided  by  Situation  Theory.  S  Sit¬ 
uation  Theory  was  enthusiastically  embraced  by  linguists  and  cognitive  scientists, 
and  found  immediate  application  in  artificial  intelligence  (Al),  a  specific  problem  iii 
knowledge  representation.  There,  Situation  Theory  is  applied  to  the  problem  of 
formally  defining  a  domain  or  microdomain  (for  our  purposes,  other  terms  for  sit- 
U(Uion)  for  each  communication.  Hence,  each  communication  has  a  foreground 
(the  information  that  is  in  the  communication  or  message  itself),  and  a  background 
(information  from  the  situation,  which  is  communicated  indirectly).  The  idea  of  an 
explicit  representation  of  the  background  information  into  ontologies  tidies  that 
Al  problem  up  nicely. 

That  solution  was  fine  for  that  near-term  problem,  but  it  established  a  new  hi¬ 
erarchy  which  has  limited  Situation  Theory,  a  division  into  foreground  and  back¬ 
ground.  This  division  places  Situation  Theory  as  a  kind  of  second-class 
mathematics  in  the  context  of  collaboration,  that  of  dealing  with  issues  secondary 
to  information  and  modeling.  Situation  Theory  brings  new  thinking  about  the  re¬ 
lationship  of  information  to  the  logic  and  Information,  but  it  has  been  divorced 
from  the  primary  communicative  act. 

It  has  been  suggested  that  the  assignment  of  Situation  Theory  to  the  back¬ 
ground  is  a  result  of  mere  fashion  in  mathematics,  for  which  there  is  no  fundamen¬ 
tal  mathematical  reason.  IfSituation  Theory  were  applied  in  the  foreground,  rather 
than  as  a  supplement  to  get  more  life  out  of  a  older  approach,  new  insights  can 
result. 

29.2  BAST96 

(The  logistical  details  of  the  first  workshop.) 

Keith  Devlin  and  Duska  Rosenberg  [DR961  have  applied  Situation  Theory  with 
some  success  to  understand  primary  communication  in  social  contexts,  and  we 
took  this  as  the  starting  point  for  the  First  Business  Applications  of  Situation  The¬ 
ory  (BAST)  workshop.  Devlin  goes  further  in  a  recent  book  IDEVL97I:  there  is  a 
need  for  a  new  approach  for  understanding  the  logic  of  human  expression  and 
communication.  Situation  Theory  provides  a  first  step  toward  this  soft  mathemat¬ 
ics. 

BAST  was  concerned  with  the  soft  mathematics  agenda  generally.  The  means  of 
approaching  that  agenda  was  to  examine  the  social  dimensions  of  collaboration  in 
business  environments  and  to  explore  the  applicability  of  Situation  Theory  to  im¬ 
part  better  understanding.  Focusing  on  business  applications  makes  the  agenda 
real,  and  the  potential  for  improved  collaboration  can  serve  as  an  impetus  for  con¬ 
tinued  work.  We  assumed  that  the  best  examples  of  this  kind  of  collaboration  are 
^typical  of  essentially  all  collective  human  efforts. 

BAST96  was  cosponsored  by  the  project  and  Steelcase,  Inc.  It  was  hosted  by  the 
Aerospace  Agile  Manufacturing  Research  Center  of  the  Automation  and  Robotics 
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Research  Center  of  the  University  of  Texas  at  Arlington.  And  it  was  facilitated  by 
the  industrial  Technology  Institute.  ^ 

We  brought  together  three  communities: 

^Mathematicians: 

^  Keith  Devlin,  Stanford  and  St.  Mary's 
^Denes  Nagy,  University  ofTsukuba 
^Jeff  Weeks,  University  Of  Minnesota  Geometry  Center 
^Scott  Baldridge,  University  of  Michigan 
^Social  Scientists: 

^Ouska  Rosenberg,  Brunei  University 

^Brian  Turner  and  Todd  Cherkasky,  Work  and  Technology  Institute 
^  Noshir  Contractor,  University  of  Illinois 
^Bill  Hutchison,  Behavior  Systems 
^Enlightened  Implementors/Practitioners: 

^Ted  Goranson,  Sirius-Beta 

^Van  Parunak,  Industrial  Technology  Institute 

^Jamle  Rogers  and  Youngmoon  Leem,  Automation  and  Robotics  Research 
Institute 

^Chris  Menzel,  Knowledge  Based  Systems 

^Arthur  Baskin,  Robert  Reinke  and  Rajaram  Ganeshan,  IMPACT  Lab,  USC 


Figure  29-1  :BAST96  Participants  (Note  Tee  Shirts!) 

The  work  plan  was  to  have  the  mathematicians  and  social  scientists  examine  the 
prior  work  of  Devlin  and  Rosenberg,  explore  new  directions  in  the  context  of  two 
inter-related,  focused  problems,  with  the  goal  of  both  indicating  viable  implemen¬ 
tation  strategies,  and  defining  a  research  agenda.  All  of  the  attendees  had  been 
chosen  in  part  because  of  their  ability  to  deal  with  complex,  interdisciplinary  is- 
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sues.  Although  the  topic  is  essentially  mathematical,  we  hope  to  speak  a  common- 
ly-understandable  interdisciplinary  Esperanto. 

We  planned  to  have  three  products  of  BAST. 

^A  general  research  agenda  to  extend  Situation  Theory  into  the  business 
domain,  specifically  as  a  framework  for  modeling  tacit  dynamics. 

^A  specific  approach  to  the  business  problem  posed  by  Steelcase.  This  problem 
(and  solution)  are  not  reported  here,  except  in  the  briefest  of  terms:  The  problem 
involved  two  elements: 

^how  to  calculate  the  learning  path  which  an  organization  needs  to  take 
when  presented  with  the  need  for  change.  In  this,  the  problem  was  more 
ambitious  than  that  posed  by  Sirius-Beta.  We  only  wanted  to  understand 
(measure)  where  Steelcase  wanted  also  to  calculate  the  action.  No 
progress  was  made  on  the  action  half  of  the  problem,  only  the  analysis  half 
shared  by  Sirius-Beta. 

^what  would  constitute  a  graphic  tool  for  such  techniques  as  the 
assessment  center  method  (a  technique  for  psychologically  measuring  and 
testing  management  skills).  A  graphic  tool  would  serve  the  same  purpose 
for  the  assessment  center  that  the  fishbone  diagram  serves  for  the  quality 
movement. 

specific  approach  to  the  problem  posed  by  Sirius-Beta  on  behalf  of  the 
project.  This  problem  statement  is  outlined  below  as  it  was  presented: 

29.3  Problemi  Soft  Metrics  for  the  Agile  Virtual  Enterprise 

(A  synopsizecJ  statement  of  the  primary  problem  pose(i  at  the  workshop.) 

The  Virtual  Enterprise  is  an  interesting  type  of  collaboration.  We  use  the  term 
enterprise  to  mean  that  in  aggregate  there  is  a  collective  goal,  which  may  not  be 
apparent  by  examining  any  single  constituent.  We  include  special  enterprises  like 
pvernment,  whose  pals  broadly  are  the  welfare  of  its  citizens,  as  well  as  the  typ¬ 
ical  business  enterprise,  whose  goals  are  relatively  more  near-term  and  more  easily 

measured.  (DARPA)  special  case  is  the  amalgamation  of  these  goals  in  the  defense 
industry.) 

The  Virtual  Enterprise  is  one  whose  constituents  are  collected  opportunistically 
when  a  need  appears  and  whose  only  bond  is  the  collective  goal.  In  this  case,  col¬ 
laboration  is  required  not  only  to  do  the  work,  but  also  to  form  the  various  special 
infrastructure)  that  permit  it  to  act  as  a  coordinated  entity.  The  most  interesting 
pd  useful  virtual  enterprises  are  ones  without  preconceptions  as  to  the  granular¬ 
ity  of  its  members,  be  they  Individuals  or  large  enterprises  themselves. 

An  Agile  Virtual  Enterprise  (AVE)  Is  one  that  can  respond  to  unexpected  change, 
not  only  when  forming  to  address  an  unexpected  opportunity  (or  disaster),  but 
^vhose  inter-unit  couplings  are  sufficiently  dynamic  to  allow  it  to  reconfigure  on 
the  fly  when  that  opportunity  unexpectedly  changes  and  to  end  when  the  oppor- 
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for  teSion*'’"  challenging  dimensions  to  the  need 

su^onTp2!"s,fn!^h!llZSd^^^^^ 

of  a  small  vocabulaiy  of  simple  communicative  acts.  The  result  is  that  all  nf  thpcp 

yond  of  the  semantic  meaning  of  the  models  and  analyze  their  topology  “ 

The  topology  of  the  transaction  is  the  onlv  charartpHcHr  t-Kat-  •  *  i 
since  it  ^lly  captures  the  dynamics  of  the  coupling  among  entities  We  abSrart^ 
ou  five  features  that  form  a  sparse  set  of  categories  that  capture 

In  the  general  case,  these  features  might  be  placed  into  a  category  space  where 

rh;fr  analyses.  Two  mathematical  ideas  are  ls7d  Thffi^^t  is 

that  the  features  {are  made  to)  form  regular,  periodic  concent  lattirec  whs^hVf 
be  manipulated  and  transformed  using  an  algebraic  eramma^  builr  nf 
primitives.  This  means  that  the  complexity  Srepfesen^^tL^^^^^^^^^ 
sunt  as  the  situations  become  comp^JatlonSKd^ 

Snrern  ™ssively  complex,  so  scaifng  is  a 

The  second  deals  also  with  the  topology  of  the  cateeorv  soarp  inm  ^uhinU 
put  these  concepts.  What  we  have  ar*;  veg^r-like  rSnuTons  o“  pts'^^ly 
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topology,  we  can  cluster  concepts-in  this  case,  agility  concepts- 
Thff  analyses  developed  for  computational  fluid  dynamics 

^pts  inSua^^  comprehend  by  looking  at  con- 

if  ^  symmetry  expert  whose  international  organization  has  a  well 
small  project  to  test  the  idea  of  a  representation  space  which  is  peri- 
odic.  This  project  IS  an  interdisciplinary  taxonomy  to  be  used  to  index  scientific/ 
scholarly  papers  for  interdisciplinary  work.  We  also  had  a  topologist  who  has  out¬ 
lined  (in  the  simplest  way)  how  a  clustering  space  might  look  with  agility  features. 

These  two  techniques  and  the  basis  for  abstracting  dynamic  categories  have 

utility  in  a  similar  space  in  the  intelligence  community 
T^he  three  previous  paragraphs  describe  the  general  case  for  enterprise  strategist’ 
but  there  is  a  simple  method  for  evaluating  the  five  agility  features  locally  for  eLh 
model  fragment.  It  involves  a  simple  algorithm  which  converts  the  model  into  an 

m'Xl'nage  “  ““<*  '’V  "  l°“" 

If  the  outline  above  occasionally  introduced  unfamiliar  topics  ail  too  terselv 
don  t  wori7.  There  only  a  few  things  that  are  most  essential  in  the  BAST  context 

known  pfnT  ff  ^0  rely  on  tool  paradigms  which  are  mature,  weli- 

f  businesses  today:  We  can  import  any  number  of  differ- 

nnin^f  ^'1.^  analytical  tools  devel¬ 

oped  for  business  analysis,  and  we  can  leverage  for  business  use  many  tools 

originally  developed  for  engineering  physical  systems.  Really  powerful  ideas,  that 
can  be  used  for  any  dynamic  characteristics,  not  only  agility. 

29.3.1  The  Difficulty  for  BAST 

(How  do  we  reason  over  situations  with  supersoft  dynamics.I 

that  we  require,  as  input,  models  whose  information  carries  the 
complete  logic  of  the  process.  In  other  words,  the  way  that  the  process  actually 
works,  Its  laws,  indeed  its  essence,  can  be  seen  in  the  model.  This  is  fine  for  aiti- 

who  supervises 

^  P'^y^^^al  processes  whose  physics  is  clear,  for  in¬ 

stance.  the  limited  number  of  ways  that  certain  parts  can  be  assembled. 

Overall,  the  metrics,  the  engineering,  of  agile  systems,  can  currently  be  apDlied 
'nfrastructure  weVe  called  legal/explicit.  This  includes  contractLnd  regult 
tions,  workflow,  and  business  processes.  Included  as  simple  cases  are  the  process- 
es  in  the  physical  infrastructure  dealing  with  logistics,  transportation,  scheduling 

by  space/time.  This  is  because  information  in  models  of  all  of 
these  processes  can  adequately  capture  the  explicit  logic  of  the  process. 

)  But  what  about  social  and  cultural  processes?  All  interesting  AVEs  will  include 

idpSp'!? ^  T  ^^oilaboration  depends  on  these  dynamics.  Indeed,  weVe 
Identified  a  Social/Cultural  infrastructure  which  covers  business  culture,  commu- 
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SiSS&lSSlHSf 

cases  we  can  model  the  behavior  but  without  undSdSia^s  at“ 
socili  tra^saXnX'rfficie“„ti;V“v^^^^^^^ 

oVs"tS  A?id'’^yrcln  SiS  shSrtc“t)? 

of  a  process  if  we  simply  know  some  behavio7o“th^cSt^hTSt'ionT‘‘®' 
Is  It  feasible  (meaning  manageable,  reliable,  and  inexpensiveP  fOne  of  mir  raqt 

solution  as  open  as  the  use  to  which  it  would  be  puf?  We'd  like  to 

sSSsSSSHSSSHE 

of  the  workplace  as  a  strategy  for  high  performance  enterprises )  Clear  v  eSh 
modeling  of  social  processes  presents  several  challenges.  ®’‘P‘'°‘ 

29.4  Memes,  Processes,  Agents,  Patterns 

Here  we  suggest  some  techniques  for  addressing  the  aeilitv  problem  in  RA<:t 
Briefly  stated,  the  problem  is:  How  can  we  model  those  orocesfpc 

There^a^re^'^*  content  in  the  same  explicit  way  that  we  model  ordinary  processes? 
There  are  several  researchers  who  add  a  social  context  to  conventional  mod/k  fn 

priSe^^f  P^^bably  the  leading 

But  we'd  like  to  do  something  else,  something  more  direct  Clearlv  we  rannnt 

do  what  we  want  if  we  pose  the  problem  in  the  conventional  wav  The  cL^fenae^ 

The^^tSform'^a^-^f  "T*  thinking  of  Situation 

1  neory  to  form  a  basis  for  a  usab  e  soft  mathematics  we  aUn  have  rn  ^ 

way  of  posing  the  problem.  Here,  we  addressee  Kr  part. 

29.4.1  The  Problem 

[The  ideal  would  be  to  discern  self-organizing  dynamics,  natural  trends.) 
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At  the  highest  level,  the  problem  is  that  we  want  to  be  able  to  understand  fea¬ 
tures  (in  the  present  case,  the  adaptability)  of  human  collaborative  processes.  The 
goal  IS  to  be  able  both  to  understand  the  general  principles  which  make  for  agilitv 

(in  given  contexts)  and  to  be  able  to  engineer  specific  enterprises  in  beneficial 
W3ys« 

A  less  imaginative  way  to  use  such  an  understandingwould  have  managers  mak¬ 
ing  many,  small  decisions  about  the  agility  of  partners  and  employers  according  to 
a  specific  strategy.  A  more  interesting  strategy  is  applied  at  the  infrastructure  lev¬ 
el,  in  unions,  schools,  and  professional  societies.  In  this  case,  we'd  encourage  be¬ 
havior,  skills,  ^d  other  phenomena  that  tend  to  self-organize  into  agile 
organizations  from  the  bottom  up.  We'll  rely  on  this  latter  view  in  our  search  for 
novel  statements  of  the  problem. 

are  workforce  issues.  The  most  advanced  thinkers  in  this  area  are 
with  the  Work  and  Technology  Institute,  also  represented  at  BAST.) 


29.4.2  The  Normal  Way  of  Looking  at  the  Problem 

ICurrent  methods  in  the  theory  keep  intent  on  the  left.  This  is  a  limitationj 

Let  s  start  by  looking  at  the  conventional  approach.  In  this  scenario,  you  have  an 
enterprise,  in  which  decisions  are  made  by  managers.  Such  an  enterprise  operates 
under  a  strategy,  conducting  a  number  of  activities  to  advance  that  strategy.  These 
are  the  basics.  In  our  view,  the  most  interesting  enterprises  are  composed  ofsmall- 
er  enterprises,  each  with  its  own  take  on  strategy  and  its  own  set  of  decisionmak- 
-j  ^  complicates  things  and  makes  it  more  difficult  to  understand  how 
ship^'°^^  disparate  companies  support  the  strategy  of  the  partner- 

That's  what  we  normally  do-look  at  activities  to  see  how  well  they  serve  the 
strategy.  Such  models  are  models  of  activities  (or  something  essentially  like  them: 
processes,  data  flow,  etc.).  In  order  to  carry  information  about  how  the  model 
works  in  the  larger  context,  innovative  modelers  use  Situation  Theory  to  add  the 
intormaticm  about  the  coupling  of  the  enterprise  and  its  strategies  to  the  process. 
It  works  after  a  fashion  to  give  the  logic  of  how  and  why  the  activity  supports  the 
enterprise  s  goals,  but  it  throws  a  lot  of  responsibility  on  Situation  Theory,  weight 
that  can  be  overwhelming  when  the  relationships  are  deep  in  the  context,  not 
readily  apparent,  soft,  coming  from  social  and  cultural  infrastrurture. 

•  of  looking  at  the  problem,  as  a  suggestion  for  facilitat¬ 

ing  BAST  discussion.  This  suggestion  preserves  the  idea  of  the  who  (the  enter¬ 
prise),  the  what  (the  strategy),  and  the  how  (the  activity),  but  gives  a  new 
perspective  on  each  which  spreads  the  mechanics  of  the  logic  Into  each  compo¬ 
nent.  At  the  same  time,  we  hope  to  extend  the  applicability  of  the  modeling  to  al¬ 
low  us  directly  to  identify  and  understand  the  importance  of  social  behavior  with 
,a  focus  on  behaviors  that  support  learning  (i.  e.,  agile)  systems. 
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29.4.3  A  Slightly  New  Perspective 

(Can  we  put  intent  on  the  right  in  a  notion  of  action?) 

egy,  and'aaM^)"th^n  brfeflySsaL^how'tW  elements  (enterprise,  straf¬ 
es  the  understanding  of  socia^l  dynamic  and  enhanc- 

open  a  more  dire«  way  to  use  Situation  Theo^)  hi  modeling  '’''P® 

29.4.4  Process 

>0  -cUons.  noU«„  of  i„,„,  in- 

howt  of  the 

the  organization,  such  as  maXti^^^  He.Sn  i,^  of  functions  in 

fused  the  structure  of  the  enterorise  wfth^r h»  ‘•'ought  this  con- 

vised  a  breakdown  of  wh^aSSSe'S^^^^^^^ 

we  recorded  the  acthritiefthaure  conduaed''b^r*  ^otvn  the  side, 

the  top,  we  collected  the  infrastruaures  that  neZS't^'^h  enterprise.  Along 
disassembled.  The  entries  of  the  matrix  aVe  th»  ^  ^  ^  created,  managed,  and 
enterprise  (AVE).  processes  of  a  typical  agile  virtual 

of  purposesTn  begin'nfng  the  metrics^Ivaluario^^^^^  "‘""•’cr 

cial  processes.  Incidentally  in  manaeement  ‘  commonly  benefi- 

ing,  such  identification  is  easy-TeanTdefineH  ’  '"enufactur- 

nearly  aiways  apply.  Agili^lfdS  in  ‘hat 

Whlf migM  consthmfan 

agile  in  another  and  could  a^cmafi/Jke^ou  irS.r.^gt?ctior ' 

cat'ofag  ,twe"rrS^^  ^“1“  Td™V  “  hrorgood 

(An  advanced  notion  of  this  is  illustrated  bv  a  °‘her  cells, 

a  demo  of  a  similar  anataVof  Sres  derive^S^^  programmed 

iWe  could  consider  this  we  need  to  have  moritf  ^  *•>  Of  course,  before 

a  way  similar  to  those  in  cells  where  processes  are  mof^wteUTd'! 
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The  bottom  line  here  for  BAST  is  that  in  the  method  so  far,  weVe  already  trans¬ 
formed  the  how  of  activity,  which  is  usually  defined  as  function,  into  process.  And 
these  processes  are  clearly  segmented  according  to  their  underlying  mechanics, 
whether  explicit  or  implicit. 

29.4.5  Agent 

|An  agent  or  action  means  something  different  in  the  social/cultural  context.) 

Conventionally,  the  unit  which  is  considered  as  the  agent  or  actor  is  the  corpo¬ 
ration,  or  in  composite  situations,  the  enterprise.  In  this  view,  there  is  a  corporate 
body,  and  each  component  plays  its  role  in  a  coordinated  whole.  Thinking  and 
commitment  comes  from  central  organs,  and  the  appropriate  parts  act  according¬ 
ly.  This  Is  neither  a  useful  nor  realistic  vision  for  the  AVE.  In  order  to  be  agile,  all 
the  parts  have  to  be  coupled  in  such  a  way  that  the  coupling  mechanism  is  dynam¬ 
ic,  meaning  that  the  organizing  intelligence  needs  to  be  distributed  somehow 
among  the  constituents.  Moreover,  in  the  real  world,  AVEs  really  do  have  distrib¬ 
uted  management  in  the  component  companies.  An  agile  response  may  be  to  de¬ 
couple  from  some  partners  and  couple  with  others. 

So  we've  turned  the  what  on  its  head  also.  In  conventional  modeling,  the  what 
is  the  enterprise;  for  our  agily  coupled  systems,  the  what  is  the  fine-grained  com¬ 
ponent,  which  has  to  act  as  an  agent.  Needless  to  say,  these  agents  must  exhibit 
some  self-organizing  behavior.  (An  expert  in  self-organizing  systems  was  on  hand 
and  available  at  BAST). 

Repositioning  the  performer  as  an  agent  who  has  self-organizing  behavior  is 
more  fundamental  than  merely  a  change  in  perspective.  Agents  and  enterprises 
both  have  capabilities  which  are  easily  modeled,  but  in  the  case  of  the  convention- 
ally-defined  enterprise,  the  coupling  occurs  through  a  control  structure;  in  the 
case  of  an  agent-defined  enterprise,  the  dynamic  coupling  occurs  through  a  risk- 
reward  structure. 

Refiguring  the  modeling  problem  to  show  the  logic  of  risk-reward  coupling  may 
be  more  manageable  in  the  BAST  context  than  looking  at  the  dynamics  of  a  social¬ 
ly-  and  culturally-influenced  enterprise  control  system.  In  particular,  it  gives  lever¬ 
age  in  the  definition  of  the  how.  This  idea  is  pursued  below. 

We  should  make  it  clear  that  we  are  rethinking  the  modeling  agenda  only  for 
the  social  infrastructure.  It  seems  clear,  at  least  intuitively,  that  all  of  the  explicit/ 
legal  infrastructure  dynamics  depend  on  an  enterprise-wide,  explicitly  supported 
control  structure.  It  is  only  within  the  dynamics  of  the  social/cultural  infrastructure 
that  we  suggest  change. 

29.4.6  Meme 

iWe  suggest  memetics  as  a  metaphoric  framework  for  one  special  element  of  actions  in  societies.) 

^  Agent  systems  have  been  studied  in  some  depth  now;  the  basic  environment  is 
one  in  which  the  behavior  is  wholly  a  result  of  local  decisions  by  the  agents.  Things 
get  more  difficult  when  one  tries  to  engineer  behavior  of  agents  so  that  the  aggre- 
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gation  of  local  events  produces  predicable,  desired  behavior.  Ifs  as  if  one  wants  to 
emulate  a  system-wide  control  system  by  designing  agents  and  their  behavior  care- 
lully.  An  6X3nipl6  of  an  application  where  this  succeeds  is  in  scheduling  systems 

where  the  applicable  laws  are  physical,  explicit,  and  logical. 

In  such  cases,  a  key  idea  is  genetic  programming;  an  idea  that  relies  heavily  on 
a  biological  metaphor.  The  mechanism  is  that  of  the  selfish  gene,  a  concept  devel¬ 
oped  to  understand  how  systems  evolve.  The  idea  is  that  genes  act  selfishly  to  rep¬ 
licate  themselves;  from  this  particular  perspective,  humans  (or  other  li\ang  beings) 
are  regarded  merely  as  part  of  a  gene's  strategy  for  replicating.  In  general,  the 
more  successful  the  system,  the  more  successful  the  replication  strategy. 

This  concept  or  observation  has  been  extended  with  the  idea  ofmemes.  Memes 
are  self-replicating  ideas  or  entities  which  can  be  seen  as  collections  of  informa¬ 
tion.  Like  genes,  they  can  exist  in  stored  form,  for  example  in  books;  and  like  genes 
they  act  selfishly.  Many  social  and  cultural  conventions  can  readily  be  seen  as  the 
evolving  result  of  interacting  memes;  this  parallels  the  way  many  characteristics  of 
biological  life  have  been  characterized  as  the  result  of  selfish  interactions  among 
genes.  Incidentally,  we  side  with  the  view  that  considers  memes  as  a  superset  or 
superclass  of  genes,  genes  being  limited  to  relatively  slow  evolution  through  bio¬ 
logical  replication.  Both  memes  and  genes  consist  of  ideas  or  information  and  both 
appear  to  act  opportunistically  to  survive. 

Why  consider  such  a  thing  a  meme?  Because  we're  getting  value  out  of  changing 
the  perspective  from  top-down  enterprise  behavior  to  bottom-up  agent  behavior. 
Much  of  that  bottom-up  behavior  can  be  understood  in  terms  of  memes.  (One 
meme,  the  idea  offairness-a  relatively  modern  concept-as  it  operates  in  collabo¬ 
rative  work  is  among  those  being  explored  by  Steelcase  and  the  IMPACT  Lab  at 
use,  participants  in  BAST.) 

We  think  there  is  value  in  looking  at  how  memes  enable  agents  to  interact  be¬ 
tween  themselves  in  order  to  further  the  desired  processes.  This  idea  ofmemes 
represents  an  inversion  of  the  strategy  of  the  enterprise.  The  enterprise's  strategy, 
at  least  in  the  social  arena,  results  from  an  aggregation  of  human  transactions  that 
serve  highly  local  risk-reward  systems.  We  believe  that  many  of  these  risks  and  re¬ 
wards  can  be  seen  in  terms  of  memes:  for  instance:  fairness,  personal  control,  be¬ 
longing,  and  expectation  of  appropriate  status. 

Engineering  agile  systems  in  the  social  context  may  mean  either  choosing  the 
right  meme  mix  (e.g.,  through  selection  of  subcontractors),  or  better,  cultivating 
the  right  memes  among  the  players  (e.g.,  by  learning  from  collaborators  to  help 
determine  what  constitutes  appropriate  risk  and  reward).  This  view  can  give  us  a 
better  insight  into  high  performance  work  forces  than  conventional  perspectives. 

29.4.7  Relevance  to  BAST 

^  [Can  we  action-like  memes  on  the  right  hand  of  situation  statements?) 

The  concept  of  the  meme  was  developed  in  order  to  illuminate  certain  large 
processes  (such  as  the  propagation  of  beliefs,  rumors,  standards,  world-views. 
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etc.).  WeVe  adopted  it  to  help  shed  light  on  another  large  process  namelv  thp  Pn. 

af  enterprises.  One  way  to  cast  the  agility  problem 

at  BAST  IS  to  describe  it  in  terms  of  the  relationship  between  the  d?nLmi«Ta 
meme  and  the  context  of  a  change  and  the  strategy  to  address  that^ change 

tn.VN  high-level  concepts:  a  situation  which  can  be  in- 

*nfon  is  a  unit  of  information  As  a  sueges- 
tion  to  start  addressing  the  problem  at  BAST,  we  propose  that  we  sefas  the 

mam  of  situations  of  interest  the  larger  world  of  commerce  which  the  entemri<;p 

componentMlgents°^^^^^^  response,  and  the  marSfold 

crifiitp  th<»  inter-relating  control  and  risk-reward  systems)  thatcon- 

tute  the  enterprise,  as  reflerted  in  constraints  of  our  infrastructures. 

chn-M  k  enterprise  consists  of  infons.  But  some  of  those  infons 

persistent  and  active,  and  so  provide  a  ready  rese^  sTL 
speak,  of  institutional  capability  to  respond  to  change  We're  not  nrnnnciria  an 

meme-'heyre  of Xem g^ 

the  use  of  the  terms  together  narrows  the  gap  between  Situation  Thpnrv  anH  thp 
agility  problem.  (Persistent  infons  of  action  at  least  resemble  the  self-replicating 
eas  called  memes.)  Perhaps  this  idea  can  facilitate  the  BAST  enterprise^  ^ 

In  Jnn  ofthis  problem  set  appears  in  its  sensitivity  to  the  incremental  evo- 

ution  of  Situation  Theoiy.  The  ability  to  understand  fully  social  colStiveil 
teraction,  much  less  improve  it,  has  been  practically  negligible  And  the  costs  of  a 
lack  of  scien^ce.  computed  either  socially  or  in  conventiSusiness 
enormous.  Therefore  any,  even  small,  improvement  means  a  lot  ’ 

Such  was  the  challenge  given  to  the  BAST  workshop  in  May  of  1996. 
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30  Results  of  BAST96 

jWe  report  the  relevant  results  so  far  as  social/cultural  metrics  are  concerned.) 


30.1  Actons 

(We  proposed  an  action-based  acton,  in  ways  symmetric  to  infons.j 

The  primary  atomic  logical  unit  in  Situation  Theory  is  the  infon.  This  is  a  result 
of  the  tradition  which  has  as  its  goal  support  of  First  Order  Logic,  the  primary  unit 
of  which  is  the  fact.  As  it  is,  Situation  Theory  has  well  developed  support  of  fact- 
based  logics  and  models  which  are  built  on  those  logics. 

But  most  of  the  useful  models  of  the  enterprise  are  based  not  on  facts  but  on 
actions.  Certainly  this  is  true  of  the  models  from  which  our  Dooley  Graph-depen- 
dent  approach  depends.  A  reason  for  action  models  over  fact  models  is  that  the 
most  useful  models  are  those  that  can  be  used  both  for  analysis  (as  with  our  met¬ 
rics)  and  for  control  of  the  enterprise.  One  can  see  a  trend  In  manufacturing  mod¬ 
eling  away  from  IDEFl-like  fact  models  to  1DEF3  and  6-like  action  models. 

So  we  proposed  introducing  a  new  entomological  construct  of  doing  to  the  ex¬ 
isting  one  of  being,  with  the  new  construct  we  termed  an  acton.  An  acton  (which 
we  denote  with  the  Greek  letter  alpha  where  infons  use  a  sigma)  has  the  minimal 
following  form:  a  set  of  preconditions,  a  set  of  postconditions  and  a  truth  value. 

The  pre-  and  postconditions  concern  what  the  states  are  before  and  after  the 
action.  These  can  be  purely  in  terms  of  infons.  But  the  intent  is  that  infons  and  ac¬ 
tons  can  co-exist,  so  the  conditional  phrases  can  be  mixed.  The  acton’s  truth  value 
is  specifically  devised  to  permit  this  sort  of  mixed  mode  inferencing,  so  it  is  similar 
to  that  of  the  infon.  One  value  is  that  the  situation  supports  the  action,  and  the 
other  of  course  that  it  does  not. 

There  was  some  disagreement  over  what  supports  means.  The  majority  felt  that 
there  are  some  deep  issues  surrounding  the  Introduction  of  the  notion  of  state 
into  Situation  Theoretic  phrases,  and  the  cleanest  handling  is  that  the  situation  is 
one  in  which  the  action  both  can  happen  and  did. 

A  minority  felt  that  the  state  issue  is  either  not  a  problem,  or  is  a  manageable 
problem  and  held  out  for  supports  to  mean  only  that  the  action  could  (for  all  we 
know)  happen,  but  that  it  hasn't,  or  alternatively  hasn't  successfully  happened.  The 
argument  for  this  is  that  the  greatest  power  of  actons  comes  when  they  can  be 
considered  as  executable  code,  and  especially  when  those  pieces  of  code  can  be 
allowed  to  interact  to  discover  emergent  behavior. 

Because  prediction  of  successful  action  completion  may  depend  on  complete 
system-wide  knowledge,  and  since  by  definition  situations  are  never  fully  defined, 
successful  completion  cannot  be  assumed. 

There  was  much  discussion  on  this.  It  was  left  with  the  majority  position  as  a 
^working  start.  And  it  was  posed  as  an  issue  for  a  BAST2,  which  will  involve  Situa¬ 
tion  Theorists  who  are  known  to  have  struggled  with  deep  issues  of  state. 
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It's  worth  noting  that  the  attempt  is  to  introduce  a  bicameral  nature  into  Situa¬ 
tion  Theory,  facts  and  actions.  This  mirrors  the  approach  which  permits  our  met¬ 
rics:  the  Dooley  Graphs  which  combine  the  notion  of  (act-related)  states  and  (fact- 
related)  performatives.  Such  bicameral  systems  are  widely  believed  to  be  essential 
for  reflective  systems,  theoretical  systems  which  can  see  and  theorize  about  them¬ 
selves. 

Soft  problems  probably  require  reflective  theoretical  capability.  This  is  because 
they  are  cognitive  aids  to  understanding  systems  which,  in  the  soft  case,  include 
cognitive  dynamics.  We'll  revisit  this  below  in  making  a  more  far-reaching  propos¬ 
al. 

30.2  Three  Kinds  of  Soft 

(We  differentiate  between  tacit  information  and  the  soft  information  which  is  our  difficult  problem.] 

We  discovered  that  there  are  several  notions  of  softness  in  information  which 
apply,  whether  fact  or  action  based: 

4Tacit:  information  which  is  not  known,  but  which  can  be  known  with  some 
effort.  In  other  words,  there  is  no  theoretical  barrier  that  prevents  the  soft  from 
being  made  hard,  explicit.  This  is  the  primary  currency  of  Situation  Theory  gener¬ 
ally,  and  the  cutting  edge  in  social  softness  deals  with  tacit  contexts  |DR96], 
which  provided  a  starting  point  for  BAST. 

4Ssoft  (Supersoft):  information  which  is  not  hard  (not  explicitly  and  logically 
stated)  and  which  has  no  existing  logical  framework  to  make  it  hard.  For 
instance,  there  are  no  Maxwell's  equations  for  group  motivation.  This  is  the  tar¬ 
get  of  the  Metrics  project,  our  Social/Cultural  Infrastructure.  In  particular,  we  are 
interested  in  the  component  we  call  Community  Cultures.  At  BAST,  we  broke  this 
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down  into  the  areas  shown. 


National,  Regional,  Ethnic 
"^Sexual,  Racial,  Religious 
-Class,  Trade,  Corporate 
^  “U  other  (Patriotic,...) 


Table  30-1 :  Ssoft  Dynamics  of  Concern 


4Ssoft  Plus:  information  for  which  there  will  never  be  capable  of  being  made 
hard.  Whether  such  a  category  exists  and  if  so  what  discriminates  it  from  Ssoft  is 
not  cogent  to  the  present  discussion.  So  we  decided  to  not  distinguish  the  two. 
However,  in  addressing  the  issues  of  state  in  BASTX  it  may  become  an  issue.  One 
can  posit  a  state  (however  costly  and  far  in  the  future)  at  which  Ssoft  information 
can  be  made  hard:  what  Devlin  and  Rosenberg  call  Zooming.  But  if  Ssoft  exists, 
such  states  may  not  always  exist.  This  possible  irresolvability  may  be  important  in 
resolving  the  state  controversy  noted  above. 


30.3  Drop  the  Meme  Baggage 

[The  suggestion  for  the  meme  metaphor  was  rejected  as  insufficiently  rigorous.| 

In  the  Project,  weVe  found  it  useful  to  employ  examples.  Where  those  examples 
deal  with  Ssoft  issues,  the  concept  of  memes  has  been  useful  as  an  expository  de¬ 
vice.  And  we  included  it  in  the  preparatory  problem  statement  for  BAST.  We  felt 
that  there  is  a  class  of  acton  which  is  not  only  capable  of  supporting  situations,  but 
also  of  modifying  future  states  of  those  situations.  These  actons  would  promote 
>or  support  some  emergent  or  self-organizing  behavior,  and  memetic  ideas  seemed 
to  fit  well. 
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However,  during  BAST  we  discovered  the  concept  to  be  seriously  lacking  in  the 
rigor  required  to  further  rigorous  dialog. 

^There  is  a  spectrum  of  people  working  in  the  area  ILYNC96)  (BROD96I,  and 
these  range  from  the  serious  to  the  pseudoscientific  with  a  preponderance  of  the 
latter.  Most  troubling  is  that  with  the  exception  of  specialized  work  on  narrow 
areas  [BL00951there  is  no  single  outstanding  seminal,  defining  work. 
iThere  are  many  cases  where  memetics  has  been  positively  used  to  help  explain 
Ssoft  dynamics,  similar  to  our  own  use  above.  But  in  those  cases,  the  application 
is  retrospective  meaning  it  sheds  some  light  on  what  happened.  No  study  exists 
which  employs  the  true  test  of  a  scientific  theory:  to  predict.  Substantial  discus¬ 
sion  on  <newsi//alt. memetics  >  has  convinced  us  that  this  is  because  of  some 
fatal  missing  capability  in  memetic  thinking. 

Therefore,  BAST  recommended  that  we  drop  the  meme  baggage,  and  find  a  bet¬ 
ter  set  of  metaphors  for  serious  investigation  into  Ssoft  and  Situation  Theory. 

We  had  already  committed  to  the  F1S96  (Foundations  of  Information  Sciences) 
meeting  to  be  held  in  Vienna  a  couple  weeks  after  BAST.  (In  fact,  we  were  on  the 
program  committee  as  well  as  that  of  another  group  (International  Society  for  the 
Interdisciplinary  Study  of  Symmetry)  which  included  an  FIS  session.)  The  FIS  mem¬ 
bers  are  specifically  concerned  with  careful  examination  of  self-organizing  natural 
systems,  and  are  interested  in  including  the  BAST  agenda.  They  asked  for  a  BAST 
contribution  (for  example  |MARI96a])  and  a  BAST  focus  in  the  next  FIS  gathering. 

Incidentally,  the  meme  idea  served  us  well  as  a  place  holder  for  a  missing  piece 
of  our  reinvented  Tool  Food  Chain.  One  guiding  roadmap  of  the  Suppliers’  Work¬ 
ing  Group  was  a  food  chain  of  dependencies.  Change  in  how  industry  engineers 
itself  is  dependent  on  tools  (such  as  those  related  to  the  metrics).  But  these  are 
dependent  on  better  tool  building  tools,  such  as  the  metrics.  The  canonical  depen¬ 
dencies  are: 

^Change  in  how  industry  engineers  its  enterprises 

i  Enterprise  engineering  tools  and  technologies 

^Tools  to  build  tools 

^Infrastructure 

^Conceptual  tools 

^Applied  math 

iPure  math 

The  following  figure  shows  that  food  chain  in  the  center,  the  current  defaults  at 
the  top  and  our  alternatives  at  the  bottom. 

30.4  Constraint  Grammars 

jWe  need  to  look  at  the  special  needs  for  soft  constraint  grammars.) 

One  of  the  useful  applications  of  Situation  Theory  is  the  ability  to  create  and  rea¬ 
son  about  Types  of  situations.  In  the  social  situation  context,  Rosenberg  (DR96j 
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Conventional  Food  Chain  Selections 


1  f  I  1  f>tructur^  LWent/SerXei  C++ 
Theory  I  I  J  1  Analysis#  iTWeb  C*^  V  (Java) 


"^rocessV 

IDEF3 


Fasten 

Better 

Cheaper 


Sematech/SWG  FC  Reference  Model 

(  Pure  ]  /  a 
I  Math  J  I  I 


eua\  Tool  Provider’s  Scope 


iia 


1  Cateqor^ 
1  Theory  J 

(  Actonsi 
1  Memes  I 
V  Agent^ 

HaTfhis 
(Basie  or 

F?l&) 

Needed 

This 

HaJ  these  proprietary  technologies 


AI^PA’s  Problem  Scope 


Figure  30-1  :We  Have  to  Innovate  at  Each  Step  on  the  Food  Chain 


has  significantly  advanced  our  knowledge  of  parameters  and  variables,  and  has  in¬ 
troduced  the  notion  of  attunement. 

But  it's  our  feeling  that  the  more  general  apparatus  of  constraints  will  need  to 
be  brought  to  bear.  We  did  not  discuss  this  in  detail  at  BAST,  but  noted  that  some 
work  may  need  to  be  done  in  this  area.  Because  situations  are  by  definition  soft 
(and  we  hope  Ssoft),  reasoning  about  them  is  necessarily  Indirect.  Reasoning  over 
their  type  domains  seems  natural. 

Characteristics  which  bound  types  are  well  handled  by  the  notion  of  constraints, 
and  as  well  there  happens  to  be  a  mature  collection  of  techniques  for  reasoning 
over  constraints.  We're  particularly  interested  in  this  as  the  generalization  of  met¬ 
rics  is  to  constraints. 

We  see  an  advanced  phase  of  the  project  looking  at  engineering  situations 
(AVEs)  for  specific  effects,  and  we  expect  that  this  will  involve  operations  over 
types.  One  stated  goal  is  to  work  with  pattern  matching  from  existing  cases,  bro- 
>ken  down  by  processes. 
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So  we  felt  that  at  least  so  far  as  new  work  in  constraint  grammars  is  concerned, 
it  may  be  better  to  consider  basing  it  on  category  theory,  which  is  well  suited  to 
dealing  with  functional  descriptions  of  types. 

30.5  Category  and  Set  Theoretical  Bases 

(Perhaps  a  category  theoretical  rethinking  of  some  mechanics  is  in  order.) 

Actually,  we  made  a  more  general  recommendation.  We  do  not  know  how  far 
the  approach  of  measuring  and  indexing  communicative  act  topologies  can  be  tak¬ 
en.  But  we  expect  quite  a  bit  further  than  we  have  gone.  And  particularly,  we  ex¬ 
pect  that  some  rules  of  thumb  can  be  derived  to  enhance  the  agility  (or  some  other 
property)  of  the  target  processes  and  system. 

This  is  a  topological  problem.  And  it  would  be  good  for  this  if  the  operators  on 
the  right  hand  side,  the  hard  side,  were  revisited  in  category  theoretic  terms  in¬ 
stead  of  set  theoretic  ones  as  it  currently  stands. 

Generally,  this  simply  responds  to  the  shift  from  fact-based,  set  logics  (languag¬ 
es)  to  action-based,  category  models  (and  languages).  Specifically,  this  shifts  the 
analytical  emphasis  to  a  bias  of  behavior-based  prediction,  rather  than  fact-based 
understanding.  It's  the  retrospective  versus  projective  issue  that  figures  so  strong¬ 
ly  in  the  business  domain. 


Old 

New 

Fact 

Action 

Noun 

Verb 

Infon 

Acton 

Set  Theory 

Category  Theory 

Static  Features 

Dynamic  Features 

Linear  Logics 

Algebras 

Hierarchies 

Directed  Acyclic 
Graphs 

Procedural 

Programming 

Functional  Program¬ 
ming 

Table  30-2:  Comparison  of  Two  Perspectives 
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Set 

Cat 

Based  on  things  (facts) 
and  relationships 
(Calculus)  among  facts 

Based  on  func¬ 
tions  and  how 
th^  are  related 

Time  captured  as  states 

Time  built  Into 
the  concept  of 
functions 

Numbers  from  collections 

Numbers  as  a 
resuit  of  physics 

Creates  an  abstract 
reailty 

Creates 
abstract 
mechanics  of 
reality 

“Behavior” 

“Physics” 

Table  30-3;  A  Comparison  Of  Set  and  Category  Theoretic  Perspectives 
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31  An  Extensible  Framework  for  Special  Tools 

iSituation  Theory  could,  if  extended,  serve  as  a  representational  framework  for  the  diverse  uses  reoresented  at 
the  workshop.] 

The  vision  that  came  out  of  BAST  was  especially  promising  because  it  provided 
a  common  framework  for  so  many  diverse  projected  uses. 

The  common  ground  is  a  sort  of  grand  convergence  of  speech  acts,  objects, 
agents,  language  insights  and  logic-based  models  under  the  umbrella  of  Situation 
Theory,  through  actons  and  related  work.  We're  not  using  Situation  Theory  as  a 
theory  so  much  as  a  representation  framework  and  a  basis  for  building  new  and  le¬ 
veraging  old  analytical  tools. 

Several  of  the  special  interest  communities  could  leverage  their  existing  work 
through  benefit  of  this  new  framework: 

^Work  and  Technology  Institute  studies  how  soft  issues  can  be  brought  to  bear 
to  create  High  Performance  Workforces  1KBMY96].  They  can  use  Rosenberg’s 
work  without  significant  extension  to  do  useful  modeling  immediately.  They'd 
like  to  do  data  mining  over  their  own  case  base. 

4The  IMPACT  Lab  at  USC  (sponsored  in  part  by  Steelcase)  was  particularly  inter¬ 
ested  in  applying  object  oriented  programming  techniques  to  create  situation- 
aware  programs. 

^in  a  similar  vein,  Industrial  Technology  Institute  (ITI)was  looking  to  merge  their 
agent  oriented  experiments  with  Situation  Theory.  ITl  has  done  a  great  deal  with 
agent-based  systems  and  emergent  behavior  for  control  systems. 

^The  Automation  and  Robotics  Research  Institute  (ARRI)  has  a  continuing  pro¬ 
gram  in  enterprise  engineering  tools  and  methods.  They  already  recognize  the 
eminence  of  social  dynamics,  but  have  no  way  of  formally  modeling  them  in  an 
explicit  way. 

^Sirius-Beta  would  like  to  perform  pattern-matching  of  implied  causal  behaviors 
of  social  systems,  using  topological  and  group  theoretical  tools. 

^Steelcase  would  like  to  be  able  to  impute  and  engineer  social  effects  from  the 
physical  infrastructure  (office  environments). 

It's  notable  that  each  of  these  approaches  expects  to  work  in  a  different  analytic 
environment,  they  each  can  see  some  value  from  a  Situation  Theoretic  representa¬ 
tion  framework. 
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32  Future  Action 

[Actions  that  will  continue  the  soft  agenda  are  noted,  including  several  things  in  the  works.) 

Cutting  edge  research  in  the  information  sciences  almost  always  has  some  key 
government  sponsorship  in  its  pedigree,  either  DARPA  or  the  National  Science 
Foundation.  Situation  Theory  does  not.  It  was  lucky  enough  get  an  early  and  sus¬ 
tained  boost  from  a  private  donation  to  Stanford's  Center  for  the  Study  of  Un- 
guage  and  Information. 

(BAST  was  sponsored  by  a  fluke  of  sorts.  A  particularly  farsighted  Steelcase  re- 

searcher  participated  in  the  AVE  Focus  Group  and  was  able  over  time  to  explain 

DACT  V  approach.  Steelcase  and  the  project  then  jointly  sponsored 

BAST.) 

Situation  Theory  is  unlucky  in  the  same  regard.  Since  it  has  no  NSF  legacy,  none 
IS  likely  to  be  forthcoming.  It's  a  highly  interdisciplinary  approach,  especially  now, 
so  It  hasn't  clearly  fallen  into  anyone's  charter  as  pure  research.  Academic  politics 
being  what  they  are,  this  could  be  difficult  to  remedy. 

But  we've  brought  an  new  application  to  Situation  Theory,  though  the  founda¬ 
tion  had  been  well  set  by  Devlin  and  Rosenberg  (DR96)  and  others.  The  engineer¬ 
ing  of  social  dynamics  in  the  business  enterprise  is  such  a  critical  component  of 
the  nation's  wealth  that  we  believe  It  manifest  destiny  that  government  sponsor¬ 
ship  as  applied  research  will  be  forthcoming. 

We  also  believe  that  we  are  not  too  far  from  a  critical  mass  where  private  invest¬ 
ment  will  appear  to  develop  specific  tools,  perhaps  along  the  lines  of  our  suggest¬ 
ed  tool  strategy. 

We'll  seek  to  have  the  work  continued; 

^  We'll  report  to  NSF  on  the  results  of  BAST  and  related  workshops,  highlighting 
the  importance  to  the  business  enterprise  and  the  probability  of  making  headway 
against  some  intransigent  problems  that  relate  to  national  wealth. 

^  We'll  suggest  that  the  Department  of  Defense,  together  with  key  prime  contrac¬ 
tors,  take  a  look  at  the  theoretical  leverage  afforded  by  even  the  most  rudimen¬ 
tary  and  incomplete  soft  modeling  capability.  After  the  debacle  of  the  B2,  and 
with  the  specter  of  the  upcoming  strike  fighter  costing  hundreds  of  billions  of  dol¬ 
lars,  even  small  real  percentages  of  effectiveness  are  worth  exploring. 

^We'll  continue  to  work  with  commercial  tool  developers  to  Introduce  these 
ideas  into  a  new  generation  of  tools  to  address  the  soft  problem  in  something 
more  than  an  intuitive  manner. 

These  three  threads  overlap  with  the  general  recommendations  for  followon 
work  as  well  as  the  tool  strategy. 

We've  already  had  BAST  1  V,  a  mini-workshop  during  the  biannual  Situation  The¬ 
ory  Conference:  Information  Theoretic  Approaches  to  Logic,  Language  and  Compu- 
}tation  (ITALIC)  in  London.  And  a  large  BAST2  is  scheduled  at  Stanford  in  the  last 

week  of  February  1997.  Results  of  that  session  will  be  posted  on  the  metrics  web 
site  at: 
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<http://www.agilityforum.org/Ex_ProjA1AVE/mave.html> 

(kindly  provided  by  the  Agility  Forum). 

There  is  also  a  BAST  mailing  list  which  can  be  accessed  at  that  site. 

We  expect  to  cobble  together  a  larger  BAST  community  by  cross-fertilizing 
among  four  groups  of  researchers  with  which  we  are  involved: 

4BAST:  The  BAST  workshops  themselves  are  likely  to  find  sponsorship  somehow 
and  continue.  The  ideas  are  just  to  strong  to  have  it  blink  out.  (Contact  Keith 
Devlin,  devlin@csli.stanford.edu,  or  Ted  Goranson,  tedg@infi.net) 

4Intemational  Society  for  Group  Theoretic  Cognitive  Science:  this  is  an  informal, 
interdisciplinary  group  which  is  tied  together  by  the  application  of  group  theo¬ 
retic  mathematical  concepts  to  various  elements  of  cognition,  reasoning  and 
knowledge.  An  email  list  is  maintained.  Contact  leyton@paradox.psych.colum- 
bia.edu  or  Ted  Goranson,  tedg@infi.net 

4 FIS:  Foundations  of  Information  Science:  the  FIS  group  supports  major  interdis¬ 
ciplinary  meetings  of  which  there  have  been  two,  both  reported  in  the  journal 
BioSystems.  What  unites  these  researchers  is  the  shared  search  for  the  science  of 
emergent,  self  organizing  behavior  in  natural  systems.  Contact  Pedro  Marijuan, 
marijuan@mcps.unizar.es,  Koichiro  Matsuno,  kmatsuno@voscc.nagaokaut.ac.jp 
or  Ted  Goranson,  tedg@infi.net 

4IntemationaI  Society  for  the  Interdisciplinary  Study  of  Symmetry:  ISIS-S  is  quite  a 
large  and  inclusive  group  which  ranges  from  the  purely  intuitive  artists  to  group 
theoretic  physicists.  The  idea  is  explore  insights  related  to  symmetry  through 
diversity.  An  interesting  quarterly  journal  is  published  and  ambitious  semiannual 
congresses  are  held,  three  already.  Contact  Denes  Nages 
nages@bukko.tsukubs.ac.jp  or  Ted  Goranson,  tedg@infi.net 

There's  a  grand  meeting/workshop  of  all  four  planned  as  part  of  the  ISlS-S  con¬ 
fab  in  October,  1998  in  Haifa.  We  plan  to  use  that  as  one  major  punctuating  point 
for  the  greater  BAST  research  agenda.  The  following  section  is  the  brief  report 
done  for  F1S96: 

32.1  Soft  Mathematics  and  Information  Dynamics 

(One  action  was  to  find  a  better  metaphoric  scaffold  for  emergent  behavior  than  memes.  We  think  we  have 
found  this  substitute.] 


32.1 .1  Foundations  of  Information  Science 

(A  second  gathering  of  interdisciplinary  scientists  to  look  at  new  principles  of  systems  with  an  emphasis  on 
emergent  behavior.  Principles  that  may  be  of  use  to  the  project's  followon  were  synthesized.) 

In  June  of  1996,  we  attended  a  remarkable  meeting  in  Vienna,  the  Foundations 
.of  Information  Science  (F1S96).  This  is  an  interdisciplinaiy  group  of  scientists, 
drawn  from  physics,  chemistry,  biology,  and  the  social  sciences  all  of  whom  are  ex¬ 
ploring  new  concepts  in  the  nature  of  information. 
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Several  of  these  researchers  had  discovered  some  deep  organizing  principles  at 
work  in  their  discipline,  that  there  was  some  self-organizing  phenomenon  at  work, 
with  information  as  the  central  agent.  Though  the  disciplines  vary,  the  basic  defi¬ 
nitions  and  underlying  dynamics  appear  in  many  respects  similar. 

Mainstream  theories  of  information,  coming  largely  from  computation  and  lin¬ 
guistics,  were  inadequate  to  support  cogent  scientific  investigation  along  these 
lines.  So  we  need  to  investigate  new  approaches  to  Information  dynamics  based 
on  these  insights.  In  various  discussions,  1  discerned  three  high-level  principles, 
which  are  briefly  sketched  below. 

32.1.1.1  Horizontal  Information  Flow 

One  conventional  view  of  the  laws  of  nature  holds  that  the  laws  are  extrinsic  to 
the  behavior  of  systems,  that  the  operation  of  the  clock  is  somehow  of  a  lower  or¬ 
der  reality  than  the  design  and  creation  of  the  clockworks.  Scientists  usually  work 
to  discover  how  a  specific  clock  works,  rarely  gleaning  Insights  into  a  larger  order 
of  things  (e.  g.  how  clocks  are  designed). 

Most  presenters  at  F1S96  showed  evidence  that,  in  effect,  the  clock  may  be  de¬ 
signing  itself,  that  the  organizing  principles  of  the  universe  are  intrinsic,  resulting 
from  certain  dynamics  of  information.  These  seem  to  include  self-replication  and 
an  evolution  of  sorts  to  higher  forms  of  information,  new  levels  of  organization. 
For  convenience.  I've  termed  this  projection  of  information  the  horizontal  flow. 
(Conrad  96  uses  the  concept  of  horizontal  and  vertical  flows.) 

Other  papers  in  this  volume  recount  cases  which  illuminate  that  horizontal  prin¬ 
ciple,  so  we  won't  dwell  on  them  here.  In  general,  the  horizontal  flow  is  from  sim¬ 
ple  (or  smaller)  systems  to  more  complex  (or  larger)  ones.  Thus,  extremes  of  the 
horizontal  flow  would  range: 

^(in  physics)  from  elementary  particle  dynamics  to  astrophysical  behavior; 

^(in  chemistry)  from  molecular  dynamics  to  the  behavior  of  materials; 

^(in  biology)  from  intracell  dynamics  to  life  in  complex  animals  and  plants;  and, 
i(in  social  systems)  from  the  dynamics  of  self  to  societal  behaviors. 

In  each  case,  it's  useful  to  describe  the  phenomenon  in  terms  of  the  behavior  of 
information,  with  the  serendipitous  result  of  providing  insight  into  why  the  law  is 
what  it  is.  The  notion  of  emergent  dynamics  (or  perhaps  self-simplifying  dynamics) 
is  central  to  this  flow  with  behavior  of  components  percolating  to  the  higher  form, 
as  in  molecules  to  crystals  for  instance,  and  back  down.  (Matsuno  93,  Marijuan  96). 

32.1.1.2  Vertical  Information  Flow 

What's  new  and  radical  in  this  prospect  is  a  possible  grand  unified  idea  of  infor¬ 
mation  for  all  sectors  of  the  universe.  Whatever  the  dynamics  of  information  in 
each  of  the  four  (or  however  many)  broad  horizontal  areas,  they  are  likely  similar 
In  important  respects,  and  effects  are  passed  on  up  the  line.  Thus,  organizing  dy- 
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namics  at  the  physical  level  support  and  contribute  to  the  chemical  level,  and  so 
on  up  and  down  a  vertical  chain  through  biological  systems  to  societies. 

This  vertical  infonriatiori  flow  is  a  generalization  of  an  idea  which  includes  inter- 
mediate  steps  (Conrad,  95).  For  instance,  an  understanding  of  many  of  the  dynam¬ 
ics  of  biochemistry  is  improved  by  considering  the  exchange  of  information 
vertically  between  chemical  and  biological  organizations. 

This  linkage  is  a  basis  for  the  interdisciplinary  agenda  fostered  by  FIS. 

32.1.1.3  Extropic  Causality 
Implicit  assumptions  include; 

4  much  of  the  information  dynamics  are  common  not  only  within  layers,  (physi¬ 
cal,  chemical  and  so  on)  but  the  propagation  of  information  between  the  hori¬ 
zontal  and  vertical  flows  may  be  similar; 

^the  underlying  impetus  is  toward  certain  self-organizing  structures,  a  selfish 
tendency  which  we  call  here  extropic,  meaning  anti-entropic;  and 

^it  is  fruitful  to  understand  the  extropic  impetus  not  only  as  it  applies  to  laws 
governing  phenomena,  but  also  the  underlying  laws  governing  the  generation  of 
other  laws.  This  would  imply  that  there  is  something  unique  about  the  topmost 
layer,  the  societal  layer  where  human  cognition  occurs. 

32. 1 .2  Importance  of  Social  Information 

IThe  social  level  (the  BAST  level)  is  the  highest  vertical  level.  Extropic  emergent  dynamics  can  only  be  meaning- 
fully  be  studied  from  that  level.] 


32.1.2.1  Relevance  to  the  Foundations  of  Information  Science  Agenda 

Several  models  of  extropic  information  systems  were  presented  at  FIS96,  repre¬ 
senting  the  bias  of  each  presenter's  discipline  and  vocabulary.  We  expect  that  each 
discipline  will  bring  concepts  and  tools  that  will  illuminate  the  whole,  but  we  ex¬ 
pect  that  the  most  powerful  underlying  formal  tools  will  come  from  the  two  ex¬ 
treme  layers  of  the  vertical  flow:  physics  at  the  bottom,  and  social  systems  at  the 
top. 

In  this  new  interdisciplinary  agenda,  we  would  expect  that  the  most  useful 
mathematical  concepts  will  be  those  which  first  found  utility  in  physics,  such  as 
group  theory,  and  ideas  of  causality  and  invariance.  (We  revisit  this  idea  below.) 
But  we  are  persuaded  that  a  very  fertile  area  for  cross-disciplinary  insight  is  the  so¬ 
cietal  arena. 

^Representing  the  pinnacle  of  the  vertical  flow,  the  social  domain  has  the  most 
complex  array  of  information  dynamics.  Insights  at  this  level  are  more  likely  to 
'  scale  down,  than  those  in  lower  levels  are  likely  to  scale  up. 

^Information  at  this  level  is  intrinsically  recursive  since  the  understanding  of  FIS 
will  be  in  terms  of  the  same  type  of  information  whose  dynamics  are  being 
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described.  This  is  not  a  trivia!  consideration. 

^Moreover,  it  may  be  the  case  that  the  selfish  dynamics  of  groups  could  add 
another  recursive  dimension  if  one  takes  the  perspective  that  they  drive  the 
extropy  of  their  own  system. 

The  bottom  line  here  is  that  we  find  it  rewarding  to  consider  the  interdisdoli- 
naiy  spertrum  of  FIS  as  a  layered  system  with  societal  dynamics  as  the  most  inter¬ 
esting,  cjj^^llengmg,  and  rewarding  case.  We  expect  an  extropic  mechanism  of 

the  goal  of  interdisciplinary  focus,  and  that  a  memetic  or  au- 
topoeitic  paradigm  may  be  useful. 


32.1.2.2  The  Business  Enterprise  as  the  Target 
Incidentally,  the  business  domain  is  a  high  value  subset  of  general  societal  inter- 

Q  w  k  I  Vx  1 1 « 

^It  is  a  well-behaved  subset.  Business  enterprises  assume  that  everyone  is  inter¬ 
acting/collaborating  for  selfish  reasons  which  can  be  economically  evaluated*  the 
goals  are  singly-directed,  unlike  general  social  enterprises. 

^Commercial  collaboration  is  primary  infrastructure  for  human  collaboration, 
providing  a  basis  for  much  else  which  organizes  society.  It  appears  that  com-  * 
merce,  broadly  defined,  predates  agriculture  and  government,  and  is  a  basic 
driver  behind  the  development  of  language.  Business  enterprises  are  currently  so 
poorly  understood  and  engineered  that  any  new  insight  could  lead  to  significant 
benefits  of  multiple  kinds.  Small  insights  will  likely  yield  great  returns. 

^Sponsorship  for  work  in  this  new  FIS  agenda  might  be  found  from  parties  inter¬ 
ested  in  the  science  behind  enterprise  engineering,  in  devising  environments 
where  creation  and  collaboration  are  maximized. 

^The  need  is  tremendous.  For  complex  systems  such  as  military  aircraft  the  vast 
majority  of  dollars  goes  to  support  societal  infrastructure  of  collaboration.  Since 
we  currently  do  this  so  poorly,  over  a  billion  dollars  per  plane  is  the  cost  in  the  B2 
bomber.  The  collaboration  cost  of  the  next  generation  is  in  the  hundreds  of  bil¬ 
lions.  Note  that  this  is  independent  of  the  engineered  and  manufactured  value  of 
the  plane,  which  Is  a  minority  of  the  cost. 

We  use  military  planes  as  only  an  indicator  of  the  general  problem.  Their  costs 
are  better  tracked  than  with  comparable  complex  systems  in  the  civil  sector 
which  is  vastly  larger  (and  more  costly). 


32.1.3  Need  for  New  Mathematics 

[FIS  needs  the  soft  math  proposed  at  BAST;  RS  scientists  could  help.) 

In  our  work,  we  have  targeted  an  agenda  of  approaching  social  and  cultural  in- 
^tormarion  dynamics  in  the  business  sector.  Specifically,  we  are  interested  in  new 
analytical  tools  and  perspectives  that  will  improve  existing  models  and  empower 
new  models  of  collaborative  enterprises.  In  doing  so,  weVe  adopted  the  FlS-in- 
spired  taxonomy  described  above,  looking  for  the  deep  physics  involved.  It  quickly 
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became  clear  that  in  addition  to  the  conventional  scientific  challenges  there  were 
fundamental  limits  in  the  mathematics  itself. 

In  particular,  the  nature  of  logic  to  examine  information  systems,  which  are  pre¬ 
sumably  elucidatable  requires  that  special  provisions  be  built  into  the  logic  to  han¬ 
dle  phenomena  which  we  don’t  fully  understand.  We'd  term  such  phenomena  soft 
phenomena,  following  the  differentiation  of  hard  (physics,  chemistry)  and  soft  sci¬ 
ences  (psychology,  anthropology).  A  mathematics  with  such  a  capability  would  be 
a  soft  mathematics.  Logics  which  are  extended  through  modes,  fuzziness  or  relax¬ 
ation  are  extended  superficially  and  are  unsatisfactory  for  this  use. 

We  conclude  that  progress  in  this  area  is  essential  for  establishing  new  concep¬ 
tual  beach  heads  m  social  information  and  providing  a  framework  for  a  layered  FIS. 

32.1.3.1  Situation  Theory  and  Soft  Mathematics 

Fortunately,  there  is  a  area  of  mathematics  which  could,  with  some  effort,  be 
leveraged  into  the  soft  mathematics  domain.  Situation  Theory.  This  work  appar¬ 
ently  began  as  a  response  to  Chomskian  linguistics,  which  looks  to  the  underlying 
Structure  of  utterances  to  understand  the  nature  of  information  conveyance.  In- 
stead.  Situation  Theory  holds  that  only  a  part  of  the  information  conveyed  can  be 
found  in  any  utterance,  that  much  of  the  information  is  held  indirectly,  in  various 
situational  and  notional  contexts. 

This  view  was  first  expressed  in  Barwise  1983.  A  substantial,  well  funded,  re¬ 
search  effort  followed,  lead  by  Stanford's  Center  for  the  Study  of  Language  and  In¬ 
formation  for  the  next  decade.  The  major  practical  result  was  the  theoretical  basis 
for  ontological  definition,  now  widely  used  in  the  knowledge  representation  com¬ 
munity.  For  the  exchange  of  information  between  machines,  this  provides  a  basis 
for  describing  the  representation  methods  used  as  well  as  basic  assumptions  about 
the  world  and  context  of  the  originator. 

A  well-developed  formal  mathematics  was  created  which  treats  situations  as 
first-class  objects  within  logics.  Situations  usually  lack  a  complete  explication  and 
are  thus  soft  objects  in  these  logical  systems.  Thus,  Situation  Theory  forms  a  ready 
basis  for  reasoning  about  soft  (meaning  not  fully  explicated)  information.  A  current 
review  of  Situation  Theory  is  Devlin  91 . 

Indeed,  Devlin  and  Duska  Rosenburg,  a  social  anthropologist,  collaborated  to 
apply  Situation  Theoiy  to  a  limited  but  practical  problem  of  cultural  mismatch  in  a 
business  setting  (Devlin  96).  And  Devlin  has  proposed  a  specific  agenda  that  lever¬ 
ages  Situation  Theory  as  a  basis  for  a  soft  mathematics  (Devlin  97). 

While  Situation  Theory  is  not,  in  itself,  a  basis  for  a  new  theory  of  information 
It  does  provide  foundations  for  a  promising  representational  framework  for  inves¬ 
tigation. 
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32.1.3.2  The  Agenda  for  Business  Applications  of  Situation  Theory 

in  June.  The  month  before,  a  project  of  the  Defense  Advanced 
Research  Projects  Agency  (DARPA)  together  with  Steelcase  Inc.  sponsored  fwork 

That  workshop  produced  three  results: 

^An  extension  of  so/Iness.  Conventional  Situation  Theory  has  the  notion  of  soft- 
ness  that  the  situation  is  not  fully  explicated  for  some  reason,  butZTt  couU 
be.  We  extended  the  notion  to  situations  for  which  we  do  not  have  the  ability  (at 

mSe^rvel' ha'!;^  -cia^psychological  d“?f'‘'' 

interest  have  no  hard,  concise  laws,  nor  any  on  the  horizon. 

as  first  class  objects.  Conventional  Situa¬ 
tion  Theory  manages  facts,  but  the  domains  of  interest  are  dynamic  with  concern 
to  the  nature  of  the  dynamics.  Therefore,  we  sketched  a  definition  for  a  uTof 
ac  ion  which  can  be  assimiiated  into  the  formalism  and  provide  some  leverage  to 

Specifically,  there  is  a  mapping  between  these  action  prim¬ 
itives  and  information-based  agents  of  some  type  that  could  exhibit  emergent 
organization,  extropy.  cmcigcni 

^The  longer  range  agenda  of  migrating  the  basis  of  Situation  Theory  from  the 
familiar  definitions  of  set  theory  to  the  potentially  more  leveragable  category 
theory.  We  expea  the  FIS  agenda  to  rely  heavily  on  the  topological  features  of 
information  and  its  carriers.  The  syntactic  view  of  category  theory  is  better 
suited  for  this  than  is  the  semantic  perspeaive  of  set  theory. 

32.1.3.3  FIS  and  BAST:  A  Promising  Agenda 

agenda  is  important.  The  scope  is  highly  in- 
pm  ^  common  vision  of  information  dynamics  will 

throulh  th/layerras'^J  key  link.  " 

carriers  or  actors.  In  both  horizontal  and  vertical  flows,  a  highly  promising 
eTexSg^ecurai*  pl^^crplS'  “““'/^“'n'raldanguage  lay- 

In  any  case  fundamentally  new  mathematical  tools  will  be  required.  Situation 

luDornt^omP^nf  to  support  a  soft  mathematics  could 

support  some  of  the  new  needs.  Fortunately,  sponsorship  of  this  agenda  is  orom- 

ising  because  of  its  business  applications.  There  is  robust  work  currently  under- 
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Part  4  is  for  those  who  need  more  detail  about  the  defense  case  and  how  to  develop  tools.  It  is  a  little  more 
technical. 


33  Abstract 

In  order  to  set  the  stage  for  a  case  study,  a  specific  missile  problem  is  noted.  We 
note  the  difference  in  the  defense  legal  system  and  explain  it  historically.  Using 
these  insights,  an  ideal  defense  supply  chain  is  proposed. 

After  giving,  in  detail,  a  scenario  we  studied  then  set  aside,  we  set  up  the  case 
study  scenario.  The  questionnaire  we  used  is  reproduced.  Then  the  results  are  re¬ 
ported.  Within  the  case  study,  we  had  occasion  to  consider  how  we  would  work 
with  methods  of  consultants;  how  we  would  integrate  with  a  representative  sys¬ 
tem  is  reported. 

We  then  turn  to  tools  whose  need  was  indicated  in  the  study.  Several  tools  are 
described.  One  of  these  tools,  the  one  most  immediately  needed  has  been  proto¬ 
typed.  It's  internal  structure  is  given  in  detail.  That  tool  automates  an  algorithm 
which  is  central  to  the  metrics.  The  algorithm  is  outlined  here. 

In  terms  of  future  tool  actions,  we  mention  our  own  special  strength  we  bring 
to  future  toolsets  and  outline  how  we  will  integrate  with  other  projects. 


Tools 

“Turnip” 

(Strategic  Concept 
Pattern  |earching) 


“Mashed  Potatoes”! 
(System-Level  View] 

4 


Steps 


Tools 


Case  Base?^ 


Sandia/ARRI/AVE 
Structured  Brainstorming 
Method 


AVE  Focus  Group 
Reference  Model 

“Pom^ranate” 
(Metrics  Extraction) 


Figure  33-1:Tools  for  Each  Step  of  the  Way 
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34  Context  For  a  Defense  Srpnarin 

|We  set  up  issues  peculiar  to  the  defense  situation  in  agility.) 

This  sertion  focuses  exclusively  on  issues  found  in  the  Defense  Agile  Virtual  En- 
terpnse  that  are  unique  to  defense.  The  purpose  is  to  provide  a  Scenario  fw  a  cas^ 

34.1  A  Serious  Problem 

|We  give  an  example  of  a  system  where  the  lack  of  agility  in  the  supply  base  is  apparent.) 

fitrhilfr  ^  Force  has  a  missile  gap,  and  this  one  is  real;  it  could  cost  lives  Our 
fighter  airplanes  (and  th^ose  of  many  allies)  rely  on  a  specific  air-to-air  missile  as  its 
primary  weapon  m  dorfghts.  (Dogfights  are  still  consWered  the  primamhreat  for 

siTe  K  cafed  "^inline  mis- 

9M  Wr  fnterdictfon  'he  AIM- 

In  1985,  U.  S.  intelligence  was  shocked  when  a  new,  then-Soviet,  air-to-air  mis- 
sile  was  observed  in  Finland.  This  missile,  which  we  call  the  AA-12  (using  the  NATO 
designation  oFAir-to-Air)  is  superior  to  our  missile  in  a  couple  of  key  areas.  If  our 

fhL  ^  ^-n  PI  combat  with  a  well-trained  MlG-29  pilot  with 

this  missile,  we  will  likely  lose.  We  could  have  met  this  missile  over  Iraq  with  di- 

flictTre^substand^  chances  of  encountering  it  soon  in  another  con- 

onH  flip?*’  as  Israel  received  word  on  the  missile  threat,  they  were  able  to  design 
and  field  a  missile  with  equal  or  superior  capabilities.  This  process  took  six  years 
and  the  missile  is  now  flying.  Subsequent  analysis  shows  that  the  original  Soviet’ 
development  took  five  years.  (The  French  now  also  have  a  fielded  response.) 

The  U.  S.  started  at  the  same  time  as  the  Israelis,  and  we  are  now  in  the  midst 
of  a  p  anned  17-year  path  to  fielding  our  answer,  the  Raytheon/Hughes  AIM-9X 
But  all  weapon  systems-every  one  in  the  U.  S.-  experiences  delays  and  cost  over¬ 
runs.  Surprisingly,  the  time  and  cost  penalties  are  amazingly  constant  and  these 
have  been  studied  and  described  by  Norm  Augustine,  currently  presid’ent  of  thf 
largest  defense  contractor  in  the  world,  in  The  Laws  of  Augustine  IAUGU831  Add¬ 
ing  in  this  constant,  we  could  be  looking  at  a  24'year  response  cycle. 

Why  does  it  take  the  US.,  the  world’s  richest  military  power,  holder  of  the  most 
advanced  nulitaiy  technology  anywhere  to  take  from  1 7  to  24  years,  under  Lvere 
threat,  to  do  what  others  can  do  in  5  or  6  years?  All  the  reasons  will  be  debated 
for  some  time  to  come.  But  at  least  one  reason  is  already  clear:  our  defense  indus¬ 
trial  base,  particularly  our  missile  supplier  base,  is  broken. 

A  recent  study  concluded  that  for  a  long  time,  beginning  shortly  after  the  begin- 
ratl  buildup,  we  have  been  losing  our  supplier  base  at  an  alarmfng 

►firul'f!  nf  profitable;  it  can  be.  It  is  because  the  dif¬ 

ficulty  of  doing  work  for  the  government,  even  as  a  second  or  third  tier  suDolier 

forces  a  company  to  commit  fully  to  being  either  a  defense  or  commercial  suoDlier 
because  of  the  way  that  processes  are  constrained.  mmerciai  supplier 
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Two  efforts  at  improving  the  Defense  Industrial  Base,  Lean,  and  CALS^,  may  have 
actually  made  some  elements  of  the  situation  worse.  A  problem  with  lean  practices 
results  from  prime  contractors  moving  to  reduce  and  prequalify  their  supplier 
base.  This  lowers  the  cost  to  the  prime  in  the  short  run,  because  it  is  easier  to  con¬ 
trol  the  suppliers,  forcing  them  to  conform  (or  preselecting  them  because  they  do 
conform)  to  a  wide  variety  of  VE-related  practices,  in  fact  ail  of  the  ones  that  the 
metrics  cover. 

This  means  that  Westinghouse  (now  Northrop  Grumman),  for  example,  will  do 
business  only  with  smaller  clones  of  itself-clones  in  regard  to  practices-and  only 
with  companies  who  provide  a  need  that  is  in  the  current  profile.  This  lowers  their 
cost  of  doing  business  within  the  relatively  small  scope  for  which  the  Westing- 
house  VE  was  engineered.  But  this  limits  a  primary  reason  for  creating  interesting 
VEs:  the  ability  to  team  with  exceptionally  different  types  of  organizations  com¬ 
pared  to  your  own  In  order  to  create  a  new  competitive  advantage. 

In  the  defense  case,  the  result  of  these  practices  is  that  what  had  been  a  large, 
flexible,  and  innovative  pool  of  businesses  has  evolved  into  a  set  of  small,  stable 
communities  that  are  associated  by  sector  and  often  by  prime  contractor.  The  re¬ 
sult  is  both  costly  and  unagile.  In  situations  where  capabilities  need  to  be 
stretched  quickly,  as  in  the  AIM-9X,  the  ways  of  bringing  new  skills  and  technolo¬ 
gies  into  this  pool  are  expensive  both  in  time  and  dollars. 

34.1.1  CALS 

(Though  beneficial  in  other  areas,  the  electronic  data  standards  effort  known  as  CALS  has  made  the  problem 
worse.] 

This  effort  began  in  the  mid-1980s  as  a  response  to  the  high  costs  of  supporting 
weapon  systems  resulting  from  poor  technical  data.  Originally  named  Computer 
Aided  Logistics  System,  it  has  evolved  through  Computer  Aided  Logistics  Support, 
in  recognition  that  what  was  needed  was  a  set  of  technologies  and  policies  for 
many  systems  instead  of  a  single  new  system,  and  then  Computer-aided  Acquisition 
and  Logistics  Support,  in  response  to  the  insight  that  processes  early  in  the  cycle 
are  involved  and  improved. 

Today  CALS  stands  for  Continuous  Acquisition  and  Lifecycle  Support  and  lately 
for  Commerce  At  Light  Speed,  the  latter  as  a  result  of  reaching  out  to  the  commer¬ 
cial  sector,  by  including  data  exchange  associated  with  simple  purchasing.  In  all 
these  incarnations,  CALS  emphasizes  standards  as  the  way  to  improve  the  ex¬ 
change  of  technical  (and  associated)  data  among  organizations.  The  primary  dis¬ 
criminator  between  CALS  and  other  standards  efforts  is  the  deliberate  attempt  to 
accelerate  useful  standards  by  imposing  them  through  mandates  on  new  weapons 
systems. 

CALS  is  designed  to  lower  the  customer’s  (DoD’s)  cost,  by  working  with  primes. 
^It  is  not  designed  to  lower  the  cost  to  subcontractors  of  doing  business,  nor  to 
make  it  faster  and  cheaper  to  associate  with  primes.  There  are  claims,  though,  that 
this  will  occur  as  a  secondary  effect,  once  the  standards  involved  become  widely 
used  and  cheaply  implemented. 
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But  the  opposite  has  in  fact  been  the  case.  The  requirement  to  use  CALS  stan- 
dards  and  conventions  is  just  one  of  a  collection  of  DoD-specific  mandates  that  col¬ 
lectively  have  forced  suppliers  either  to  focus  on  narrowly  answering  the  mail  or  to 
^ve  up  and  abandon  the  Defense  Supplier  Base.  So  agility  in  the  VE.  early  in  th^ 
^cle,  IS  compromised  in  order  to  effect  savings  to  the  customer’s  view  of  the  prod- 

Moreover,  since  the  standards  don’t  look  at  re-engineering  the  processes  thev 
have  an  additional  effect  of  technologically  freezing  existing,  possiblv  obsolete  ^ 
business  processes.  Naturally,  this  further  counters  the  ability  to  change. 

^  unsophisticated  view  of  process 

Ln  5  y  lowering  the  cost  of  exchanging  product  data  across 

an  existing  business  or  functional  boundary.  Agility  adds  the  more  advanced  di- 

at  process  integration  in  including  novel  business  arrange- 
^S[*'^/^*ues  the  adoption  of  enlightened  management  techniques 
rnd^ffidafsta^d"^^^^^  relatively  crude  instruments  of  mand^ates 

34.2  Defense-Peculiar  Issues 

IWhat's  unique  about  the  defense  enterprise  is  the  legal  system.  All  else  is  as  it  is  in  the  civil  sector.) 

To  what  extent  is  defense  a  special  case? 

Elsewhere,  we’ve  looked  at  various  ways  in  which  agility  can  be  measured  We 
have  settled  on  an  agenda  which  looks  at  how  well  (in  an  agile  sense)  an  entity  can 
aggregate  and  change  its  business  boundaries  once  aggregated;  also  of  interest  is 
how  agile  the  entity  is,  and  how  agile  is  the  aggregate 

We  suggest  that  the  former  view  is  the  most  comprehensive,  greatly  informing 
the  oth^ers.  Al^,  for  each  view  of  agility,  the  organizing  entity  is  different  and 
might  have  different  elements  of  agility  that  would  be  measured.  Here  we  need  to 
look  at  the  nature  of  that  organizing  entity. 

We  have  Justified  our  initial  focus  on  the  formation  of  the  for-profit  defense 
manufacturing  virtual  enterprise.  There  is  reason  to  ask  whether  all  the  other  ao- 
phcations  of  interest,  save  one,  will  fall  out  of  a  rigorous  look  at  our  focus.  What 
are  the  differences  between  the  commercial  and  the  Defense  AVE  (DAVE)? 

First,  some  observations  about  the  DAVE.  Different  types  of  decisions  are  made 
concerning  each  of  the  four  infrastructures  in  the  DAVE 

I  in  the  Social/Cultural  infrastructure  is  motivation  At 

least  at  the  individual  level,  patriotic  motivation  is  a  force  not  found  in  the  com¬ 
mercial  arena;  it  could  be  a  significant  differentiator.  It  has  been  suggested  that  a 
security  environment  profoundly  affects  the  group  dynamic.  But  it  is  not  clear 
whether  that  is  a  cultural  issue,  since  it  is  a  matter  of  rules  and  policy. 

,  It  has  also  been  suggested  that  the  social  dynamics  are  often  influenced  by  po- 
itical  issues:  for  example,  a  weapon  system  may  be  built  or  not  depending  on  the 
congressional  representation  of  a  critical  mass  of  its  VE  partners.  Does  this  haPDen 
in  the  commercial  sector?  Airbus,  Long  March,  DeBeers  are  only  a  few  cases,^or 
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many,  politically-driven  closed-market  situations  found  in  the  commercial  world. 
We  don’t  see  this  as  unique  to  the  DAVE. 

Concerning  the  Physical  infrastructure,  there  aren’t  many  special  issues.  It 
seems  to  many  observers  that  the  plants  and  equipment  are  largely  similar.  Excep¬ 
tions  have  been  proposed  for  nuclear,  biological,  and  chemical  weapons  manufac¬ 
ture,  but  even  here  there  are  similarities  with  many  commercial  enterprises. 

Sophistication  is  not  an  issue.  In  some  process  equipment  technologies 
is  more  sophisticated,  but  in  others  they  are  not.  Overall,  at  root  there  are  no  dis¬ 
criminators. 

The  Information  infrastructure  issues  are  also  similar.  There  are  only  P^’ 
sible  elements  which  could  be  different.  One  is  security,  but  that  is  essentially  c  - 
mon  {with  the  exception  of  the  rules  noted  below).  One  case  which  was  studied 
had  an  aircraft  operation  which  was  so  concerned  with  stealth  geometry  that  its 
IrformatrneeTperturbed  the  entire  operation  "^«„We  argue 
this  specific  motivator  for  the  perturbation  is  unique  to  defense,  but  that  many 
similar  perverting  influences  exist  in  both  sectors. 

One  final  element  is  the  need  for  individual  parts  tracking  in  soine  DAVEs.  Th  s 
was  pointed  out  in  a  dual-use  plant  where  the  parts  were  maintained  so  separately 
that  the  processes  were  in  fact  forced  to  be  dissimilar.  But  again,  we  sugge«  that 
this  resufts  from  differing  rules  (the  Legal/&plicit 

information  infrastructure  needs.  Bottom  line:  there  are  no  differences  here. 

Many  differences  are  apparent  in  the  domain  of  the  Legal/Explicit  infrastructure. 
The  differences  fall  into  three  categories:  the  external  imposition  of  the  Work 
Breakdown  Structure  which  determines  the  business  boundaries  among  partners; 
fhfextZal  of  policies  and  procedures  in  the  actual  processes;  and  the 

common  case  where  reimbursement  is  accounted  by  the  process  and  not  by  the 
product’s  value,  because  free  market  conditions  do  not  apply. 

In  the  case  of  selling  weapons,  there  is  often  another  factor:  the  n^d  to  have  a 
government  third  party  involved  either  as  an  agent  or  as  a  regula  or.  However,  we 
will  not  list  this  as  a  difference,  since  there  are  many  commercial  technologies 
which  are  controlled,  and  many  other  commodities  which  are  subject  to  the  same 
influences  through  tariffs,  ceilings,  and  so  on. 

The  discussion  above  presumes  that  the  VE  is  defined  in  the  same  way  for  de¬ 
fense  and  commercial  work,  namely  as  the  aggregate  of  the  entities  which  artually 
do  the  work.  In  this  model,  the  DoD  is  external,  playing  the  same  role-customer- 
-as  the  marketplace  does  for  commercial  AVEs. 

We  don’t  make  that  assumption;  instead  we  assume  the  defense  customer  plays 
a  role  in  the  DAVE  as  a  bona  fide  entity.  This  expands  the  search  for  discriminators 
that  we  summarized  above,  and  it  raises  questions  about  who  is  the  organizer  in 
a  DAVE,  the  DoD  or  the  prime  contractor. 

)  If  we  exoand  the  scope,  issues  in  the  Physical  Infrastructure  show  a  real  differ¬ 
ence  The  Li  S  DoD  is  the  world’s  largest  and  most  distributed  enterprise.  The 
phylicaf  magnitude  0/'^  itself  if  a  discriminatot.  And  if  DoD  is  involved  in  a 
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physical  presence  of  the  DAVE  is  (often)  brought  to  a  dynamic 
defense  contractors  had  sites  condguous  to^the  ac 
of  Uniformed  combat  support  pefsonneHs  liLIv 
.ni  -K  ^ Phenoinenon.  So  a  possible  difference  is  in  the  pETdisDeS 

wlS together  " 

rio?rK?c^  foforniation  infrastructure  side,  the  acquisition  infrastructure  in  DoD  is 
Jhtr  ^  the  command  and  control  infrastructure.  In  recent  history 

this  was  reinforced  with  a  decision  to  move  advanced  acquisition  resSrch  S 

this^’wa^s^^mistT^^^^  cV®  ^5^-  open-access  internet  channels.  Arguably, 

Cultural  issues  change  in  this  new  situation.  The  patriotic  motivation  becomp«; 
more  pronounced  when  your  actions  seem  both  to  benefit  society  and  to  save  in¬ 
dividual  lives.  It  s  not  clear  this  is  unique  to  DAVEs.  There  are  for-profit  life-savina 

m/  fnr*^P  (emergency  hospitals  and  safety  in  the  nuclLr  power  indus¬ 

try,  for  example).  There  are  enterprises  driven  by  a  sense  of  social/pnvlrnnm^ 

responsibility  (Tom’s  Toothpaste,  Ben  and  Jerry’s^ce^ 

es,  such  as  unions,  where  the  collective  benefit  is  important.  ^ 

^he  depth  of  patriotic  commitment 
but  I  think  the  dynamic  is  the  same.  There  is  no  substantive  discriminator  i^^the  ’ 
social  area.  Patriotic  rnotivation  is  one  of  a  number  of  similar  motivators  The  dif¬ 
ference  between  it  and  the  other  motivators  doesn’t  matter  in  the  agile  context 

So,  the  real  d Terences  come  in  the  Legal/Rules  infrastructure,  and  it  is  here  that 
we  propose  to  direct  the  discussion  to  the  role  of  the  organizer 

'^hich  DAVEs  are  different  from  commercial  AVEs-  the  cus- 
3  large  extent.  Intuitively,  we  assume  that  much 
activity  of  the  organizer  is  in  the  creation  of  the  legal/ 
regulatory  infra^structure.  And  it  has  been  seen  that  the  actual  rules  differ  between 
commercial  and  defense  enterprises.  It’s  only  fair  to  assume  that  the  difference  in 
rules  results  from  the  role  of  the  customer  as  organizer. 

•M  an  additional  set  of  agility  metrics  applicable  to  the  DAVE*  these 

he  orlr h^  >  ‘m  customer  and  the  ability  of  partners 

to  be  organized  by  it.  Moreover,  the  context  will  involve  some  DAVE-peculiar  rules 

organlzfr’^contVoT^  centralized  influence  over  processes  as  an  effect  of  the 

acquisition  bureaucracy  is  the  organizer/customer  rep¬ 
resenting  both  the  congress  and  the  combat  user.  ” 
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34.3  A  Key  Difference:  The  Engineering  Paradigm 

|The  legal  system  difference  can  be  traced  to  a  different  engineering  philosophy;  the  customer  controls  the  pro¬ 
cesses.) 

Agility  is  a  broad  concept  which  can  be  applied  in  a  wide  variety  of  scenarios.  In 
order  to  focus  the  test  cases  for  the  metrics,  we’ve  chosen  to  concentrate  on  one 
scenario  beyond  others.  In  no  way  do  we  mean  to  imply  that  the  metrics  apply  to 
only  this  scenario.  But  it  does  help  to  assume  a  specific  context. 

Our  Focus  Scenario  is  directly  targeted  at  the  DoD  problem,  as  well  as  common 
commercial  situations.  We  focus  on  agility  in  the  supplier  base;  we  assume  a  prime, 
which  acts  as  an  organizer  of  the  VE.  Agility  of  the  prime,  in  this  scenario,  is  con¬ 
sidered  differently  than  agility  within  the  subcontractors. 

In  the  case  of  the  prime,  we  consider  only  its  ability  to  agily  organize  a  VE  con¬ 
sisting  of  itself  and  several  primes,  ideally  with  the  ability  to  use  novel  business 
interactions.  It  has  an  ability  to  adjust  internally  that  is  essential  to  serving  this  or¬ 
ganizing  strength.  Potentially,  there  may  be  certain  agile  issues  that  don’t  contrib¬ 
ute  to  strength  in  organizing  AVEs.  For  simplicity’s  sake,  we  ignore  them  in  this 
scenario. 

Considering  the  subcontractors,  we  focus  on  their  ability  to  be  cheaply  and 
quickly  organized,  and  reorganized,  into  an  AVE.  There  may  be  other,  unrelated 
types  of  agility  within  each  subcontractor.  These  are  ignored  in  this  focused  sce¬ 
nario. 

It  should  be  noted  that  it  is  widely  believed  that  the  agility  on  which  the  scenar¬ 
io  focuses,  and  that  which  it  does  not,  are  either  identical  or  closely  related.  But 
there  has  been  no  rigorous  investigation  of  the  relationship;  this  is  an  area  for 
someone  to  investigate  further. 

The  focus  scenario  has  special  applicability  to  defense  issues.  Commercial  mar¬ 
ket  forces  are  not  the  major  driver  In  the  defense  sector.  In  the  commercial  envi¬ 
ronment,  the  prime  determines  the  nature  of  the  product,  and  offers  it  to  the 
customer.  Listening  to  the  customer  requires  special  skills.  In  the  defense  sector, 
the  customer,  DoD,  defines  the  product  or  need,  often  in  precise  detail.  So,  market 
forces  that  are  at  work  in  the  commercial  sector  are  less  clear,  or  absent,  in  the 
defense  sector. 

The  result  is  that  greater  stability  is  more  desirable  in  defense  primes  than  in 
commercial  primes.  The  agility  that  is  required  is  the  ability  to  quickly  and  cheaply 
supplement  some  in-house,  protected  core  competencies  with  a  fluid,  robust  sup¬ 
plier  base.  The  value  that  each  defense  prime  brings  is  its  set  of  core  competencies 
plus  its  ability  to  create,  manage,  and  adapt  a  team.  The  focus  scenario  is  con¬ 
cerned  with  these  values,  which,  as  it  happens,  are  particularly  apt  for  the  missile 
community. 

^34.4  A  Desirable  Future  State  of  Affairs 

[Here  we  suggest  an  ideal  situation  as  a  strategic  goal.) 
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Here  we  suggest  an  AVE  scenario  that  is  a  special  case  of  the  agile  defense  sup¬ 
plier  chain  just  described.  This  future  state  of  affairs  recognizes  that  defense  needs 
are  substantially  different  than  commercial  needs,  and  possibly  will  always  be  so. 

We  believe  that  it  is  unproductive  to  try  fundamentally  to  change  the  way  that 
the  DoD  relates  to  its  prime  contractors.  That  relationship  has  no  commercial  an¬ 
alog.  Unfortunately,  that  is  currently  where  most  of  the  attention  for  acquisition 
reform  is  mistakenly  engaged.  But  that  is  not  where  the  costs  from  not  being  agile 
are  being  incurred;  rather,  it  is  in  the  relationships  with  first  (and  later)  tier  suppli¬ 
ers.  We  would  like  to  see  a  high  degree  of  agility  there,  which  implies  ease  of  mov¬ 
ing  from  being  a  supplier  of  commercial  goods  and  services  to  defense  and  back. 

There  are  three  inter-related  ideas  that  make  this  vision  possible: 

^No-clause  contracts, 

skills/process  certification  agent(s),  and 
^lndemnifier(s)  for  unexpected  events. 

We  outline  all  three  below.  The  metrics  need  to  provide  information  on  them 
all,  but  also  to  provide  a  necessary  enabling  foundation  for  the  third. 

34.4.1  No-Clause  Contracts 

(An  Ideal  would  be  contracts  that  contain  only  what  is  to  be  done,  relying  on  case  law  for  what  happens  when 
things  go  wrong.) 

We  recognize  that  large,  centralized,  FAR-based  contracts  between  the  govern¬ 
ment  and  the  prime  will  be  with  us  for  some  time  to  come.  But  ideally,  we’d  like 
to  do  away  with  the  passing  down  of  all  the  baggage  to  the  supplier  base,  which 
in  most  cases  adds  over  half  of  the  value  of  the  weapon  system. 

Currently,  the  ponderous  responsibilities  of  the  prime  are  passed  wholesale  to 
the  suppliers.  It  is  a  matter  of  assigning  risk.  In  the  commercial  world,  if  a  part  fails 
and  lives  are  lost,  for  example,  the  supplier  of  that  part  may  be  liable.  But  in  the 
defense  world,  if  the  supplier  did  exactly  as  it  was  told,  if  it  confornied  to  all  the 
process  and  other  specifications  passed  down  to  it  by  those  above,  it  is  not  liable. 

Most  of  the  military  systems  of  interest  do  involve  the  possibility  of  substantial 
loss  of  life  by  their  actual  customers,  so  those  in  the  system  will  not  give  up  this 
indemnification  unless  something  substantially  better  emerges. 

For  this  future  scenario  to  work,  we  need  all  three  innovations  noted  above.  The 
first  of  these  is  a  greater  reliance  on  the  case  base  for  that  component  of  the  FAR 
which  deals  with  corporate  ethics  and  contractual  responsibilities.  It  should  be 
possible  to  encourage  prime-sub  contracts  which  mandate  ethics,  but  rely  on  the 
case  base  instead. 

We  believe  that  when  successfully  applied,  the  result  is  great  agility  and  an 
openness  of  the  marketplace  to  commercial  and  start-up  entities.  More  important, 
^ve  believe  that  the  cost  savings  to  the  system  will  be  greater  than  the  additional 
costs  of  litigation  that  the  system  could  promote.  In  the  movie  industry,  this  is 
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clearly  the  case,  and  economic  studies  done  to  commercialize  the  formerly-Soviet 
supplier  base  indicate  that  it  could  also  have  been  so  there. 

In  other  words,  we’d  like  to  see  the  same  prime-sub  contracting  principles  we 
see  in  the  most  agile  commercial  systems. 

34.4.2  A  Process  and  Skill  Certifying  Agent 

(Another  ideal  would  have  an  agent  that  brokers  partners  and  certifies  skills.| 

Part  of  the  reason  for  the  unwieldy  contract  provisions  for  subcontractors  is  to 
ensure  that  processes  will  integrate  well  when  the  VE  is  formed.  Certainly,  this  is 
an  important  issue;  it  won’t  happen  of  its  own  accord  with  high  confidence,  so  the 
DoD  makes  it  happen,  ensuring  that  it  will  happen  by  specifying  and  requiring  spe¬ 
cific  processes  in  detail. 

The  problems  with  this  are  well  known;  the  costs  of  avoiding  fraud,  waste,  and 
abuse  are  greater  than  the  sort  of  waste  they  seek  to  avoid.  Even  in  the  case  where 
the  overall  process  integration  is  good,  it  differs  from  commercial  practice  and/or 
preferred  practice,  so  it  costs  more.  But  often  the  military  specification  is  not  bet¬ 
ter,  or  even  as  good  as,  commercial  practice.  Maintaining  these  specifications  is  a 
large,  expensive  job.  Many  of  the  processes  of  relevant  interest  evolve  rapidly,  and 
it  is  impossible  for  the  central  authority  to  catch  up. 

The  alternative  to  rewriting  defense  specifications  to  conform  to  commercial 
ones,  or  substituting  formal  military  specifications  for  formal  commercial  ones, 
can  only  partly  and  insufficiently  solve  the  problem.  We  would  still  have  a  lumber¬ 
ing  central  engineering  authority  mandating  processes.  Federation  among  the 
partners  in  the  VE  is  required,  but  we  cannot  have  anarchy  in  the  process  selection 
and  certification. 

But  we  do  have  an  agent  involved  that  is  close  to  the  processes  and  has  what 
could  be  the  proper  mix  of  federation  and  central  coordination-unions.  The  de¬ 
fense  industry  is  heavily  unionized.  That  this  is  so  should  be  no  surprise:  large,  brit¬ 
tle  organizations  attract  strong  adversaries  in  order  to  preserve  justice  and 
balance  in  the  workforce  where  needed. 

Where  the  role  of  the  union  has  in  the  past  often  been  reactionary,  a  new  role 
can  be  carved  out.  Why  not  respond  well  if  the  unions  were  to  return  to  their  her¬ 
itage  in  the  guilds?  It  is  entirely  possible  to  envision  the  union  as  an  agent  which 
certifies  that  the  skills  of  a  worker  is  adequate,  that  the  processes  that  the  workers 
use  across  many  firms  are  consistent  and  readily  integratable,  and  that  those  pro¬ 
cesses  represent  best  practice. 

We  believe  that  this  is  possible.  The  positive  role  that  unions  are  currently  play¬ 
ing  in  exploring  agility  (at  The  Work  and  Technology  Institute  in  Washington  DC) 
is  encouraging,  and  we  believe  this  goal  to  be  theoretically  within  reach.  By  the 
way,  this  approach  (agile  unions)  would  reflect  another  structural  advantage  that 
fthe  U.  S.  has  over  its  competitors  and  adversaries. 
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Both  the  lightweight  contract  and  the  certification  agent  depend  heavily  on  be¬ 
ing  able  to  protect  themselves  from  unexpected  and  extreme  circumstances. 
Therefore  an  agility-based  indemnifier  is  required  as  a  necessary  condition. 

34.4.3  An  Agility-Based  Indemnifier 

|The  third  ideal  would  be  an  insurer  who  evaluates  agility  and  lowers  risk  costs.] 

The  final  big  idea  of  the  three  is  more  centrally  based  on  agility.  We  want  VEs 
to  form  quickly  and  cheaply  and  to  work  in  key  respects  as  well  as  centrally-man- 
dated  enterprises.  But  the  question  always  arises:  who  gets  stuck,  if  something  un¬ 
expected  happens? 

The  cases  that  are  interesting  are  high-value,  complex,  high  technology  systems 
that  must  perform  with  very  high  quality,  and  whose  technology  is  always  new  and 
changing.  Something  always  goes  wrong  in  creating  these  systems;  that’s  the  na¬ 
ture  of  the  beast.  If  it  were  not  so,  agility  would  not  be  so  important. 

We  propose  another  agent  in  the  system,  an  indemnifying  agent.  We  believe 
this  would  be  a  relatively  minor  outgrowth  of  an  existing  insurance  industry,  which 
in  fact  performs  a  similar  function  today  in  the  movie  business. 

How  it  would  work  is  this:  the  parties  (prime  to  supplier,  or  supplier  to  supplier) 
agree  to  do  certain  things  assuming  not  much  untoward  occurs;  this  is  our  light¬ 
weight  contract.  Also,  at  a  fine  level  of  granularity,  the  unions  certify  skills  and  pro¬ 
cesses,  but  this  also  assumes  that  not  too  much  deviation  from  the  base  case 
occurs. 

A  third  party  evaluates  the  situation,  and  judges  the  ability  of  the  suppliers  in 
combination  to  respond  to  the  changes  that,  while  unexpected  in  detail,  can  be 
reasonably  expected  overall.  That  agent  is  paid  to  cover  problems  outside  of  the 
planned  base  case. 

Two  things  happen.  First,  the  system  automatically  becomes  less  brittle,  be¬ 
cause  every  competitor  is  going  to  want  to  have  its  capabilities  within  the  ability 
to  respond  to  change.  They  will  want  to  lower  their  insurance  cost  as  a  business 
matter.  This  means  that  normal  market  forces  will  be  brought  into  play  not  only  to 
give  incentive  for  agility,  but  also  to  reward  the  VEs  that  have  achieved  the  best 
balance  of  agility  versus  insurance. 

Second,  a  new  cost  is  added  into  the  system,  that  of  paying  for  insurance  for 
possible  events  to  which  the  system  could  not  previously  respond  well.  This  new 
expense  should  be  far  less  than  the  amount  saved,  because  of  the  effect  that  it  will 
have  on  building  agility  within  the  VE  and  because  of  the  costs  avoided  from  cen¬ 
tralized  management. 
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35  An  Alternative  Scenario 

|We  set  up  an  alternative  defense  aerospace  scenario.) 

Our  case  study,  which  we  describe  below,  has  fairly  modest  aspirations.  We  take 
a  typical  Type  3  AVE,  led  by  a  conventional  prime.  We  target  agility  in  the  supply 
base  and  have  a  specific  ideal  in  mind.  (The  three  characteristics  described  above 
are  given  not  as  a  realistic  state,  but  an  ideal  vision.)  But  there  is  another  cogent 
DAVE  scenario  which  we  did  not  pursue.  Perhaps  it  even  more  meaningful. 

The  defense  acquisition  system  is  based  on  the  idea  of  designing  and  manufac¬ 
turing  the  right  system.  It's  supposed  to  be  apt  for  the  missions  and  reflect  the 
most  beneficial  product  and  process  technologies  when  fielded.  Essentially  all 
manufacturing  research  is  design  research,  to  increase  the  changes  of  getting  it 
right  the  first  time.  Concurrent  Engineering  (CE)  and  Integrated  Product  and  Process 
Development  (IPPD)  are  two  examples  of  this  thinking. 

They  address  the  famous  wisdom  that  most  of  the  cost  of  the  system  is  set  very 
early  in  the  life  of  the  design.  CE  and  IPPD  allow  more  iterations  and  alternatives 
in  that  short  period,  and  carefully  provide  for  insight  into  the  downstream  impli¬ 
cations  of  early  decisions. 

But  something  is  wrong.  That  can  never  be  sufficient  in  dynamic  situations 
where  technology  and  missions  continue  to  change  throughout  the  whole  life  cy¬ 
cle,  not  just  the  first  20%.  History  shows  that  essentially  no  major  weapon  system 
has  been  right  the  first  time.  It's  just  impossible,  and  more  likely  in  current  times 
as  missions  evolve  more  quickly  than  in  the  past.  Technology  changerate  is  in¬ 
creasing. 

Our  alternative  scenario  addresses  lowering  the  cost  of  getting  it  right  the  sec¬ 
ond  (or  third...)  time,  by  relaxing  the  period  of  time  that  design  decisions  need  to 
be  frozen.  In  the  defense  environment,  all  major  design  decisions  must  be  made 
in  the  very  early  phases  because  you  need  to  lock  in  your  suppliers  (and  their  pro¬ 
cesses).  It's  the  way  the  system  works. 

The  Work  Breakdown,  who  does  what,  becomes  a  part  of  the  legal  fabric  of  con¬ 
tracts  and  responsibilities.  If  the  supply  chain  were  agile,  if  the  members  and  pro¬ 
cesses  could  change  in  midstream,  then  basic  design  decisions  could  be  changed 
much  later  at  low  cost-  indeed  all  the  way  through.  We  did  not  work  through  this 
important  scenario  in  the  case  study  because  it  assumed  unrealistic  changes  in  ac¬ 
quisition  law.  We  wanted  a  scenario  that  a  prime  could  implement  today. 

For  reference,  we  worked  through  an  example  with  this  alternative  scenario  and 
distributed  it  directly  to  key  firms,  and  posted  it  on  the  web  site  for  a  year.  The 
general  feeling  was  that  similar  costs  would  apply  if  the  metrics  were  used  in  this 
scenario,  but  with  greater  benefits  to  the  Department  of  Defense.  A  summary  of 
that  alternative  is  given  below. 


5.1  Background 

[Who  you  are  (a  defense  prime),  what  your  goal  is  (in  winning  contracts).) 
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Time  - ► 

Figure  35-1  :An  Agile  Supply  Chain  Allows  Design  Changes  to  be  Made  Later 

In  this  scenario,  you  work  for  an  aerospace  prime  contractor  which  supplies  tac¬ 
tical  missiles  to  the  U.  S.  Department  of  Defense  (DoD).  The  situation  is  highly 
competitive,  and  you  are  going  head-to-head  with  a  competitor  for  an  important 
air-to-air  missile  contract,  which  may  affect  your  chances  for  survival.  This  is  quite 
a  real  scenario  in  today’s  environment. 

You  and  your  competitor  compete  on  cost,  which  hurts  you  both.  But  you  could 
get  extra  points  for  advanced  technology  in  your  product  in  the  contract-awarding 
evaluation.  However,  your  DoD  customer  is  sensitive  to  and  avoids  technology-in¬ 
duced  risk  in  its  project. 

Both  of  you  are  starting  with  similar,  low-risk  technical  approaches,  but  you 
have  a  smart,  inventive  engineering  staff.  It’s  probable  that  they  can  come  up  with 
design  alternatives  late  in  the  design  life  cycle,  well  past  the  ordinary  time  it  takes 
for  you  (and  your  competition)  to  adjust  your  supplier  chain. 

What  agility  can  do  for  you:  if  you  have  agility  built  into  your  supplier  chain,  so 
that  it  can  adjust  to  major  redesigns  late  in  the  game,  you  can  win  the  contract, 
and  win  it  on  advantageous  terms. 


35.2  Your  Company’s  Possibilities 

[You'd  like  to  keep  design  options  open  until  late  in  the  engineering  cycle.] 

As  we’ve  said,  your  company  makes  missiles,  and  they  have  decided  (through 
the  strategic  planning  process)  that  competitive  leverage  can  be  gained  by  focus¬ 
ing  on  technology  improvement  in  the  design  of  the  steering  system.  You  and  your 
competition  were  planning  on  using  metal  fins,  which  is  a  low-risk  decision. 
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However,  your  company’s  engineers  have  two  design  possibilities  that  would 
greatly  increase  the  performance  of  the  missile  and  improve  your  chances  of  win- 
ning.  But  both  design  options  won’t  be  ready  until  late  In  the  development  cycle, 
^ie  normally  freeze  your  production  assets,  In  this  case  your  supplier  ' 

This  missile  is  controlled  by  metal  fins  at  the  rear  of  the  missile  tube.  The  first 
opnon  IS  to  replace  the  metal  fins  with  ones  made  of  an  advanced  composite  ma- 
terial.  These  would  be  both  lighter  and  capable  of  standing  higher  temperatures. 
Most  important  is  that  because  the  material  is  far  stronger,  the  fins  can  be  larger! 
rnaking  the  missile  more  maneuverable.  The  customer’s  evaluation  criteria  value 
that  performance  improvement.  It  means  that  you  would  be  competing  on  product 
performance  rather  than  cost;  your  company  would  much  rather  have  a  high 
chance  of  winning  on  performance,  than  take  a  scant  chance  of  winning  on  cost. 

The  other  design  option  is  to  do  away  with  fins  altogether,  making  the  rocket 
nozzle  out  of  the  same  composite  and  gimbaling  it  so  that  steering  fins  aren’t 
needed.  Adoption  of  this  option  would  guarantee  winning  the  contract  on  merit 
and  open  possibilities  for  profitable  growth  in  the  product  line. 

Unfortunately,  your  engineers  will  not  be  able  to  engineer  sufficient  risk  out  of 
these  alternatives  until  200  days  before  production  in  the  first  case,  and  100  days 
before  in  the  second.  Your  normal  best  date  for  freezing  these  decisions  is  300 
days,  which  is  controlled  by  lining  up  and  preparing  suppliers.  At  the  200  and  100 
day  marks,  your  engineers  expect  to  be  able  to  tell  you  for  sure  whether  the  op¬ 
tions  are  viable.  ^ 

Therefore,  your  company  seeks  sufficient  agility  in  the  supplier  base  for  this  sec¬ 
tion  of  the  missile  to  allow  them  to  adapt  to  the  alternatives  If  your  engineers  can 
get  the  designs  ready  by  engineering  out  unacceptable  product  risk. 

35.3  Structured  Brainstorming 

(You  brainstorm  your  strategies.) 

Inddentally,  the  strategic  planning  is  a  directed  series  of  simulations,  conducted 
at  different  levels  of  detail.  The  idea  is  to  discover  the  strategies  that  are  most  ben¬ 
eficial  and  include  conventional  non-agile  features,  as  well  as  the  agile  ones  we 
add. 

But  such  simulations  are  usually  directed  by  the  senior  management  on  the  ba¬ 
sis  of  Intuition.  Our  investigations  of  the  dynamics  which  support  the  metrics  have 
also  indicated  a  structured  brainstorming  method  which  can  direct  the  strategic 
simulations.  Since  it  is  relevant  to  the  example,  we  outline  it  here. 

The  idea  is  that  the  best  agility  will  leverage  natural  forces  in  the  business  envi- 
ronment  and  will  key  off  of  strengths  that  occur  in  the  enterprise  seemingly  of 
their  own  volition.  We’ve  used  the  concept  of  a  meme  from  the  study  ofself-orga- 
►nizing  systems.  A  meme  is  a  self-perpetuating  entity,  usually  an  abstract  entity  of 
some  kind,  which  adapts  and  spreads  on  its  own.  For  example,  the  common-law 
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Note:  this  chart  is  different  from,  but  related  to,  the  one  which  shows 
costs  of  design  freezing. 


The  probability  of  a  commitment  is  in  the 
area.  The  three  options  have  dependent 
probabilities  (option  #1  is  not  shown),  so 


Figure  35-2:You  Must  6esign  the  Supply  Chain  for  the  Probability  of  These  Late 

Changes 


based  no-contract  contract  of  the  whaling  example  is  a  meme  which  adapted  to 
survive. 

We’ve  found  a  meme  which  is  associated  with  centralized  control  and  code¬ 
based  contracts,  which  has  a  French/Latin  heritage,  and  a  competing  meme  based 
on  decentralized  control  and  common  law  (the  invisible  hand  ofthe  market)  which 
has  a  Viking/English  history. 

The  structured  brainstorming  approach  is  based  on  a  few  basic  religious  issues. 
Participants  play  roles,  often  taking  a  religious  perspective  or  world  view  that  is 
contrary  to  that  which  they  normally  hold.  This  has  been  effectively  developed  as 
promising  tool  by  the  AVE  Focus  Group. 

What’s  interesting  about  the  defense  sector  is  that  it  has  an  unhappy  mix  of 
these  two  memes,  the  central  planning  one  in  the  relationship  between  the  cus¬ 
tomer  and  the  prime  and  the  decentralized  meme  in  the  relationship  between  the 
prime  and  its  suppliers.  This  is  a  major  cause  of  difficulty  in  the  defense  sector  a 
difficulty  which  is  not  found  in  its  civil  counterpart. 

This  is  such  an  important  factor  in  the  missile  sector  that  we  have  structured  the 
scenario  to  illustrate  agility  that  spans  the  influence  of  the  two  memes.  Strategic 
planners  in  the  missile  example  would  have  looked  at  the  advantageous  implica¬ 
tions  of  agility  in  this  respect  and  planned  to  Include  those  considerations  in  their 
virtual  manufacturing  simulations. 

|35.4  Results  Of  The  Strategic  Planning 

|As  a  result  of  the  strategy,  you  are  given  supplier  options,  a  target  and  an  agility  budget.] 
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Your  company’s  planners  have  employed  the  metrics  in  a  Virtual  Manufacturing 
scenario,  looking  for  breakpoints  in  the  risk-payoff  curves.  (This  process  is  based 
on  the  same  metrics  and  is  also  addressed  by  our  project,  but  is  beyond  the  scope 
of  this  example.  It  was  through  the  strategic  planning  process  that  the  engineers’ 
decision  dates  and  associated  probabilities  were  established,  as  well  as  the  profit¬ 
ability  of  pursuing  this  agility  strategy. 

What  they  have  provided  you  Is  an  agility  budget: 

^Which  transactions  with  potential  suppliers  are  expected  to  be  important 

^Which  features  (described  later)  of  those  transactions  are  important,  with  a 
weighting  factor  for  each 

^An  agility  bogey  (or  goal)  for  each  instance 
^An  agility  budget 

35.5  Your  Agility  Budget 

(How  you  could  spend  your  budget.) 

The  budget  that  you  have  been  given  is  25%  over  the  baseline  cost  of  the  metal 
tins.  Included  in  this  budget  Is  the  cost  of  changing  suppliers  from  the  one  planned 
to  supply  the  metal  fins.  LandFin  is  the  supplier  selected  for  this  job,  being  the  best 
On  terms  of  cost,  time  and  quality)  only  when  the  metal  fin  design  is  considered. 
They  have  no  experience  with  composites,  so  would  not  be  an  agile  choice  But 
they  are  your  baseline. 

The  25%  budget  does  not  Include  added  cost  to  the  product  proper;  that  Is  con¬ 
sidered  m  the  decision  by  engineering/management  in  whether  to  go  with  it  or 
not.  But  It  does  include  the  cost  of  having  a  ready  supplier  base. 

You  can  spend  the  money  as  you  wish.  Examples  of  how  you  may  chose  to  spend 
your  budget:  ^ 

^Increasing  your  internal  ability  to  support  the  change,  for  example  in  acquiring 
specifications  related  to  composites 

^As  contract  termination  fees  to  discontinued  suppliers 
^As  fees  to  keep  suppliers  hot 

4As  funding  to  help  suppliers  leanVhire  consultants  or  insource  skills 

^As  funding  for  your  cost  to  transfer  skills,  processes  and  equipment  to  a  sup¬ 
plier 

35.6  Probabilities  Of  Change 

(The  likelihood  that  things  will  change,  requiring  agility  in  the  supplier  base.) 

Management  has  consulted  with  the  engineering  staff  and  determined  a  balance 
for  deading  to  go  with  either  of  the  two  options.  The  composite  nozzle  option  has 
'a  cutoff  date  for  when  the  risk  will  be  engineered  out  of  the  system  design.  That 
date  is  200  days  before  production.  A  similar  cutoff  date  of  100  days  is  given  for 
the  composite  fins,  because  it  will  perturb  the  overall  design  of  the  missile  less. 
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Your  job  in  effect  is  to  design  the  risk  out  of  the  supplier  base  of  making  these 
design  changes  late  in  the  game. 

The  planners  believe  that  there  is  a  20%  chance  of  going  with  the  novel  nozzle, 
and  a  50%  chance  of  going  with  the  composite  fins. 

35.7  Your  Alternatives 

(Now  with  a  specific  supplier  choice,  what  your  options  are.) 

In  order  to  address  this  problem,  you’ve  decided  to  investigate  four  alternatives 
using  the  agility  metrics  to  determine  the  one  which  is  most  agile  (together  with 
other  metrics  which  measure  conventional  time  and  cost  criteria): 

^Alternative  #1:  Stay  with  LandFin,  and  pay  them  to  develop/insource/outsource 
the  needed  capability 

^Alternative  #2:  Reselect  a  single  supplier  based  on  agility,  and  engage  with 
them  to  support  the  needed  changes 

^Alternative  #3:  Reselect  2  or  3  suppliers  based  on  pure  capability,  paying  all  to 
stay  hot,  and  planning  to  terminate  two. 

^Alternative  #4:  Reseiect  2  or  3  suppliers  based  on  both  capability  and  agility, 
and  also  engage  with  them  to  support  the  needed  changes 

The  practical  use  of  the  metrics  will  be  In  evaluating  candidates  for  the  alterna¬ 
tives,  and  in  evaluating  the  alternatives  themselves,  against  the  company’s  aeilitv 
strategy.  t'  j  e  y 


Single 

Supplier 


Multiple 

Suppliers 


1 

Go  with  Landfin  and 
pay  them  to  develop/ 
insource/outsource 
the  needed  capability 

2 

Reselect  a  single  sup¬ 
plier  based  on  agility, 
and  engage  to  sup¬ 
port  the  changes 

3 

Reselect  2  or  3  based 
on  pure  capability, 
paying  all  to  stay  hot 
and  planning  to  termi¬ 
nate 

4 

Reselect  2  or  3  based 
on  agility  and  engage 
with  all  to  support  the 
needed  changes 

Passive  Active 

Agility  Agility 


Figure  35-3:Your  Choices 


35.8  The  Infrastructure 

|The  first  modeling  step,  decomposing  processes  according  to  the  Reference  Model.) 


Fttruary  15/ 1997 


291 


Part  4.  Tool  Stratei 


Creating  and  managing  a  Virtual  Enterprise  is  a  matter  of  creating  and  managing 

InfrastruSures'^^^*^  first  job  is  to  parse  the  infrastructure.  We’ve  found  four  major 

^Information  Infrastructure  (supporting  communication  and  language  behavior) 
^Social/Cultural  (nonexplicit  processes) 

^Social  Laws  (hardwired  laws  of  human  behavior) 

^Community  Cultures  (National,  class,  and  ethnic  value-driven  behavior) 

4  Business  Culture  (CompanyA^E  specific  value-driven  behavior) 
^Legal/Explicit  (explicit,  non-physical  processes) 

4  Contracts/Regulations 
EBusiness  Processes 
^Workflow  Processes 
^Physical  (explicit,  physical  processes) 

^LogisticsAVarehousing  (material  handling) 

^  Equipment/Plant 
^Physical  Laws 

^  °  infrastructures  are  given  elsewhere.  The  metrics  currently  focus 
on  the  Lepl/Rules  infrastructure  with  aspirations  to  grow  into  the  Social/Cultural 
mfrastructure.  The  example  focuses  on  the  Contracts/Regulations  division  of  the 
legal  infrastructure  for  these  reasons: 

^The  modeling  dynamics  or  mechanics  within  the  infrastructure  are  the  same 
regardless  of  the  subarea. 

^The  contracts  area  is  most  closely  linked  to  Social/Cultural  mechanics 

In  the  defense  dornain,  we’ve  discovered  some  interesting  mechanisms  regard¬ 
ing  how  the  contracting  infrastructure  (specifically  the  relationship  between  law 
and  engineering)  works  and  have  traced  its  history  and  that  of  the  conflicting  tra- 

%  but  WstoS^  only  caus- 

The  contracts  subinfrastructure  in  your  company,  that  part  that  deals  with  your 
relationship  to  suppliers,  is  further  broken  down,  for  example,  into  the  following 
kinds  of  concerns  (as  well  as  others):  ® 

^Quality  Assurance  Provisions 
^Liability/Benefit  Accrual 

^Issues  Associated  with  Intellectual  Property  Development 
^How  to  Insert  New  Technology 
^Disaster  Recovery  Plan 

Each  one  of  these  will  be  handled  as  an  individual,  contributing  component  with 
metrics  that  evaluate  its  agility  in  the  strategic  context.  At  the  end,  the  compo¬ 
nents  will  be  added  using  the  weighting  factors  passed  down  from  the  strategic 
planning  effort.  The  resulting  metric  will  only  tell  you  the  time  and  cost  associated 
with  change.  Those  time  and  cost  figures  will  be  added  to  other,  conventional  time 
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and  cost  metrics  which  measure  each  supplier’s  effectiveness  at  production.  The 
result  will  tell  you  in  quantitative  terms  which  is  the  lowest  time  and  cost. 

35.9  Modeling 

[A  review  of  the  steps  in  the  modeling  process.) 

The  approach  requires  that  the  process  be  modeled.  Fortunately,  we  only  model 
the  small  fragment  of  the  action  that  concerns  change.  It  is  not  necessary  to  model 
the  entire  enterprise  to  extract  the  agility  information.  A  large  number  of  modeling 
or  representation  techniques  can  be  used,  which  allows  you  to  use  the  tools  with 
which  you  are  familiar,  or  which  coordinate  well  with  other  analyses. 

The  process  is  one  which  starts  with  a  model  and  ends  with  a  model,  the  para¬ 
metric  model  which  is  in  fact  the  metric.  Along  the  way  we’ll  perform  four  opera¬ 
tions:  ^ 

We’ll  constrain  the  models  to  the  areas  of  the  VE  that  are  of  concern.  We  do  this 
primarily  because  it  helps  literally  to  shape  the  model  the  way  we  want.  But  it  also 
helps  in  identifying  those  areas  of  the  VE  where  missing  or  incomplete  models 
might  exist.  Then,  we’ll  constrain  the  models  so  that  each  major  process  conforms 
to  a  communicative  act  as  formally  defined  in  the  literature. 

The  third  step  is  deriving  something  called  a  Dooley  Graph  of  each  model  and 
counting  that  graph’s  main  structural  features.  This  process  is  formal  and  straight¬ 
forward  and  results  in  a  numerical  function.  In  the  final  step,  all  of  the  functions 
from  the  small  model  fragments  we’ve  been  considering  are  summed  in  a  weighted 
manner  to  yield  the  agility  of  the  system. 

All  of  these  steps  can  be  performed  manually,  without  automated  help.  But  we 
plan  to  build  tools  that  support  each  step  of  the  way,  making  the  process  easier 
for  our  tactical  manager. 

35.10  Parsing  the  Enterprise 

[Breaking  down  the  Legal/Explicit  infrastruaure.j 

The  metrics  described  in  the  example  will  all  come  from  the  Legal/Explicit  infra¬ 
structure,  meaning  those  processes  in  the  enterprise  which  are  explicit.  We’ll  be 
creating  or  abstracting  many  small  models  of  special  processes  of  interest.  The  in¬ 
frastructure  breakdown  determines  how  many  small  models  there  are  and  what 
each  one  contains.  It’s  important  that  the  models  be  clean,  capturing  only  the  in¬ 
formation  from  each  perspective  of  a  process. 

The  first  decomposition  of  the  Legal/Rules  infrastructure  Is  into  three  main  ar¬ 
eas: 

^Contracts/Regulations:  This  includes  legal  issues  of  course,  formal  and  informal. 
External  issues  are  the  laws  within  which  the  VE  operates.  Internal  Issues  are  the 
'  contracts  which  bind  the  VE  together  and  to  the  customer.  This  collection  of 
models  drive  the  risk/reward  system.  Models  used  to  define  these  processes  are 
often  different  from  the  others  since  the  processes  have  different  dynamics.  Most 
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notable  is  the  notion  of  what  is  true.  In  this  domain,  truth  is  equated  with  what  is 
admissible. 

EBusiness  Processes:  This  area  concerns  the  structure  of  how  the  business  oper¬ 
ates.  For  instance,  who  reports  to  whom,  who  evaluates  performance,  who  certi¬ 
fies  certain  elements,  like  engineering  processes,  are  all  central  to  this  area.  The 
processes  captured  here  explicitly  distribute  the  risk/reward  tokens  within  the 
enterprise. 

^Workflow  Processes:  This  final  component  of  the  infrastructure  deals  with  the 
actual  processes  of  getting  the  work  done.  In  manufaauring,  it’s  the  collection  of 
value-added  operations  of  the  product. 

Most  activities  span  all  three  of  the  areas.  A  product  component  may  move 
through  the  factory  being  operated  upon,  its  route  and  state  may  be  affected  by 
supervisory  control  (say,  an  inspector),  and  it  most  always  has  a  state  that  is 
tracked  by  a  contract  space  (say,  an  activity  based  costing  system). 

Capturing  each  of  the  state  changes  individually  and  independently  is  intuitive 
and  easy  to  do.  But  it  could  in  some  cases  require  substantia!  work  to  tease  these 
three  threads  from  existing  models. 

35.1 1  Identifying  Agility  Transactions 

|An  overview  of  how  the  metrics  are  calculated.) 

The  method  depends  on  the  view  of  an  agile  system  as  a  collection  of  dynami¬ 
cally  coupled  processes.  A  key  concept  is  the  decomposition  of  the  elements, 
which  are  coupled  into  a  standard  form,  and  the  subsequent  analysis  of  the  cou¬ 
pling. 

We  standardize  the  decomposition  by  constraining  by  infrastructure  and  com¬ 
municative  acts  (which  are  described  below).  But  we’re  jumping  ahead  to  explain 
why.  The  focus  is  on  the  nature  of  the  transactions  which  couple  the  standard  pro¬ 
cesses. 

That  transaction  boundary  has  five  features  which  indicate  agility: 

^Distance:  measures  the  difference  between  the  handling  of  processes  on  either 
side  of  the  transaaion  boundary.  If  they  are  similar,  changes  in  one  side  (assum¬ 
ing  a  control  hierarchy)  can  be  employed  at  the  other.  More  similar  is  generally 
more  agile.  A  contracts  example:  using  the  same  accounting  and  legal  mecha¬ 
nisms  on  both  sides  of  the  boundary  increases  agility  of  that  component. 

4Time  Delay:  measures  the  time  it  takes  to  complete  a  token’s  passing.  A  token 
is  the  item  delivered  and  the  payment  received  in  the  for-profit  case.  If  the  time  is 
short,  the  coupling  is  tight  and  the  messages  to  change  will  be  faster.  A  contracts 
example:  if  the  compensation  accounting  can  be  coupled  to  a  finer  granularity  of 
work,  it  Increases  the  agility  of  that  component. 

4MoveabiIity:  measures  the  ability  to  relocate  the  boundary  elsewhere.  If  the 
boundary  is  moveable,  it  can  be  adjusted  right  into  the  supplier,  or  left  into  the 
prime,  can  change  granularity  or  handle  a  different  parsing.  A  contracts  example: 


F ctruary  15/  1997 


294 


Part  4,  Tool  Strategy 


if  the  contracts/business  boundary  can  be  moved  to  include  some  of  the  prime’s 
responsibilities  by  the  supplier  without  changing  the  contract  mechanism,  it  is 
more  agile. 

4Importance:  measures  the  ratio  of  the  complexity  of  this  transaction  to  that  of 
the  entire  enterprise.  If  the  importance  is  high,  the  local  granularity  of  the 
decomposition  is  large.  In  a  centrally  controlled  paradigm,  this  would  be  more 
agile;  in  a  paradigm  with  decentralized  control,  it  would  be  less  so.  A  contracts 
example:  if  one  set  of  terms  and  conditions  covers  a  large  set  of  possibilities, 
then  the  contract  is  more  agile,  assuming  a  conventional  prime-controlling  para¬ 
digm. 

4Frequency:  measures  the  ability  to  increase  the  rate  of  the  transaction.  If  the 
boundary’s  rate  of  exercise  can  be  increased  (within  scope)  without  changing  the 
mechanism,  that  mechanism  is  more  agile.  Contracts  example:  increasing  the 
quantity  of  products. 

The  immediate  goal  of  the  process  is  to  identify  all  of  the  transactions  that  con¬ 
tribute  to  each  of  the  infrastructures.  In  this  example,  there  are  three.  Further, 
we’ll  characterize,  by  means  we  introduce  soon,  all  of  the  five  features.  The  result 
will  be  a  matrix  of  five  features  by  three  infrastructure  areas.  Each  cell  will  have 
several  entries,  since  each  infrastructure  area  has  many  processes  of  interest. 

35.12  Communicative  Acts 

[The  metrics  are  based  on  communicative  arts.| 

The  idea  of  prototypical  communicative  acts  is  a  central  concept  we  use  in  eval¬ 
uating  each  of  the  model  fragments.  The  idea  is  an  important  step  in  developing 
an  agility  function  for  each  of  the  model  fragments.  It  is  based  on  a  well  under¬ 
stood  theory  of  communication  that  has  been  stable  for  decades. 

The  basic  idea  is  that  each  of  the  units  of  behavior  of  interest  in  the  enterprise 
fall  into  one  of  only  a  very  few-exactly  seven-acts.  It  is  possible  to  form  each  unit 
of  behavior  so  that  it  reflects  exactly  one  of  these  acts.  It  will  soon  become  appar¬ 
ent  that  forming  the  model  in  terms  of  these  acts  is  essential  to  the  evaluative  pro¬ 
cess. 

The  seven  acts  are  divided  into  speech  acts  and  non-speech  acts.  Non-speech 
acts  are  constrained  to  either  ship  or  pay.  These  constitute  the  final  actions  that 
define  the  business,  transaction  boundary.  If  we  were  applying  the  agility  metrics 
to  not-for-profit  activities  (government,  universities,  combat  teams),  we’d  need  to 
substitute  others. 

If  the  transaction  boundary  is  internal  to  an  organization,  as  most  are,  then  the 
ship  and  pay  acts  may  not  be  the  most  intuitive.  Ship  is  the  value  added  that  the 
unit  of  behavior  in  the  organization  contributes.  Pay  is  the  cost  of  supporting  this 
unit  of  behavior.  Note  that  activity-based  costing  philosophies  help  with  this  de¬ 
composition,  but  the  actual  costs  are  not  of  interest  here. 
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The  remainder  of  the  acts  are  speech  acts.  They  support  the  fundamental  trans¬ 
actions  of  ship  and  pay  which  define  the  transaction  boundary.  They  are  of  two 
types:  solicit  and  assert. 

Solicit  acts  are  request  and  question.  An  example  of  request  is: 

“Please  send  me  50  widgets  by  next  Thursday.” 

An  example  question  might  be: 

“What  is  your  capability  to  provide  widgets?" 

Assert  acts  are  inform,  commit,  and  refuse.  An  example  of  inform  is 
“I  don’t  have  50  widgets.” 

A  commit  statement  might  be: 

“I  plan  to  send  you  50  widgets  at  catalog  price  by  next  Thursday.” 

Refuse  is  seen  in: 

“I'm  abandoning  my  commitment  to  send  you  40  widgets  at  catalog 
price  by  next  Friday." 

Identifying  and  aggregating  units  of  behavior  to  match  these  acts  is  intuitive  and 
easy.  With  a  little  support  from  a  tool  or  style  guide,  that  aggregation  is  unique. 

35.13  Final  Infrastructure  Decomposition 

(Back  to  the  example  now,  we  look  at  the  legal  infrastructure.! 

With  those  concepts  briefly  introduced,  we  are  ready  to  return  to  the  scenario. 
Because  it  is  the  most  novel,  we’ll  focus  on  the  contract  subdivision  of  the  Legal/ 
Explicit  infrastructure. 

The  decomposition  to  this  level  is  the  same  no  matter  what  business  you  are  in. 
But  we  need  to  go  one  level  down,  and  that  decomposition  varies  from  sector  to 
sector. 

In  our  missile  example,  the  types  of  processes  that  are  of  relevance  include 
Quality  Assurance  Provisions  as  well  as  others.  Of  these,  we’ll  focus  on  contract 
support  for  QA  in  the  suppler-to-prime  relationship.  It  is  interesting,  and,  in  the 
case  of  switching  from  metal  fins  to  one  of  the  composite  alternatives,  shows  a  rev¬ 
olutionary  type  change  in  the  VE’s  contracts  infrastructure. 

35.14  Modeling  The  Quality  Assurance  Process 

(Within  the  legal  infrastructure,  we  focus  on  quality  assurance  as  an  example  process.l 

Fortunately,  parsing  the  infrastructure  into  these  components  results  in  very 
simple  processes.  Here,  we  are  only  concerned  with  contract  support  for  QA,  not 
the  entire  process.  In  the  baseline  case,  the  case  where  you  have  a  single  supplier, 
LandFin,  and  are  buying  the  metal  fins,  your  QA  is  driven  from  above.  From  the 
^contracts  point  of  view,  the  sole  purpose  of  the  QA  process  is  to  satisfy  the  cus- 
'  tomer  and  indemnify  yourself  against  claims. 
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In  the  baseline  case,  you  use  a  conventional  (for  defense  primes)  approach:  You 
get  a  first  article  from  the  supplier,  you  destructively  test  it,  and  then  you  put  into 
place  an  mspertion/certification  process  that  ensures  that  the  supplier  is  meetine 
the  relevant  military  specifications.  By  the  terms  of  your  typical  defense  contract 
if  you  do  these  two  things,  you  are  indemnified  from  future  damages.  In  this  case 
you  understand  how  to  test  the  fins  and  you  own  the  test  equipment. 

Your  source  model  will  record: 


4 1 .  Request  for  QA  items  from  LandFin 

42.  Receive  the  first  article 
^3.  Test  the  first  article 
44.  Accept  the  design,  or 
^5.  Reject  the  design 

^6.  In  the  case  of  4,  Get  the  process  certification  plan  (which  tests  for  mil-spec 
compliance) 

47.  Evaluate  the  plan  for  its  ability  to  protect  you  and  satisfy  the  customer 
^8.  Accept  the  plan,  or 
^9.  Reject  the  plan 

You’ll  also  iTiodel  the  QA  processes  of  the  alternatives  from  the  contracts  per¬ 
spective.  But  either  of  the  composite  options  are  quite  different.  Let’s  say  that  your 
pmpany  has  no  experience  with  composites.  In  particular,  you  own  no  compos¬ 
ites  test  equipment,  nor  do  you  have  any  related  test  experience.  You  can  specify 
performance  of  the  composite  part,  but  you  have  no  way  of  testing  it;  you’ll  have 
to  count  on  the  supplier  for  that.  Also,  DoD  has  no  relevant  specified  processes  for 
composites  of  this  type,  so  you’ll  have  to  ask  the  supplier  to  guarantee  processes. 

Note  the  radical  difference  here.  In  the  baseline  case,  all  of  the  contract  process¬ 
es  are  geared  toward  indemnifying  you  through  the  customer.  In  any  of  the  alter¬ 
natives  an  of  the  contract  processes  are  geared  to  ensuring  indemnification 
through  the  supplier.  This  is  quite  a  change. 

The  alternatives  all  share  the  same  model,  recording: 

4 1 .  Request  for  indemnification  plan 

42.  Receive  the  plan 

^3.  Examine  the  plan  to  see  whether  the  guaranteed  performance  of  the  product 
meets  your  needs,  and  to  ensure  that  their  plan  indemnifies  you 
44.  Accept  the  plan,  or 
^5.  Reject  the  plan 

^In  the  cases  of  alternatives  #2  and  4,  where  you  have  decided  to  take  action  in 
case  of  a  deficiency  in  the  supplier,  the  model  goes  on.  In  these  cases,  the  action 
would  be  to  help  them  acquire  a  competency  that  makes  them  capable  of  indem¬ 
nifying  you.  For  example,  you  may  loan  them  money  for  test  equipment,  or  use 
search  skills  to  find  them  a  subcontractor  to  fill  their  need.  The  extended  model 
for  these  cases  is: 
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^6.  In  the  case  of  5,  Get  help  from  a  third  party 
41.  Install  the  assets,  loop  to  2 

Capturing  the  information  for  you  was  easy  because  it  uses  intuitive  concepts, 
doesn’t  force  me  to  model  the  entire  VE  in  order  to  understand  contracts,  and 
would  have  allowed  reuse  of  diverse  models. 

35.15  Quantizing  The  Model 

[Here's  how  the  metrics  are  derived.) 

The  novel  approach  of  the  metrics  is  the  idea  of  topological  abstraction  which 
is  a  category-theoretic  idea.  Simply  explained,  this  approach  is  based  on  the  fact 
that  if  phenomena  are  constrained  in  certain  ways  in  their  representation,  then 
substantial  information  can  be  obtained  by  looking  at  the  underlying  form  of  the 
expression. 

A  simple  example  would  be  in  the  parsing  of  sentences,  an  exercise  that  we  all 
did  in  primary  school.  One  can  tell  a  great  deal  from  the  parsing  diagram  without 
getting  into  the  actual  meaning  of  the  sentence.  For  instance,  one  can  know 
whether  it  is  a  question,  a  joke,  or  a  command.  Especially  with  methods  which  are 
more  advanced  than  the  old  school  sentence-diagramming,  one  can  get  a  good  feel 
for  whether  the  thoughts  expressed  are  more  complex  or  colorful  in  one  sentence 
than  another.  A  Judgment  can  be  made  whether  there  is  a  more  complex  thought 
behind  the  sentence.  Actually,  there’s  been  a  substantial  amount  of  work  on  such 
structural  deductions  of  constrained  representations  [GORA92h|;  it’s  Sirius-Beta’s 
specialty. 

A  truly  accurate  metric  would  involve  some  nonintuitive  abstraction  that  would 
probably  be  machine  assisted,  and  this  is  absolutely  required  when  using  the  met¬ 
rics  for  strategic  planning  (Virtual  Manufacturing  simulation).  But  a  quite  accurate 
approximation  of  static  agility  can  be  made  using  manual,  intuitive  methods.  The 
trick  is  to  reduce  the  model  to  a  Dooley  Graph.  This  graph  essentially  captures  the 
complexity  of  the  transactions  involved. 

The  Dooley  Graph  consists  of  nodes  and  links,  and  looks  much  like  a  simple 
translation  of  the  model  with  the  parties  as  the  nodes  and  the  communicative  acts 
as  the  links.  It  differs  in  having  multiple  editions  of  the  parties  as  multiple  nodes. 
When  a  new  conversation  is  initiated,  a  new  edition  of  the  initiating  party  is  cre¬ 
ated,  with  links  showing  the  speech  acts  as  appropriate. 

The  result  is  a  simple  diagram  which  reveals  a  surprising  amount  of  information 
about  the  transaction  mechanisms,  information  that  tells  us  all  we  need  to  know 
about  the  important  elements  of  changing  from  one  type  of  transaction,  say,  our 
base  case  of  customer  indemnification  for  metal  fins,  to  one  of  our  alternatives 
which  relies  on  supplier  indemnification. 

The  Dooley  Graph  for  the  base  case  breaks  your  company  into  two  parties,  the 
^contracts  department,  and  the  engineering  department,  which  for  contracts’  sake 
is  a  different  entity,  and  each  of  these  has  two  conversations.  It  also  breaks  down 
the  supplier  into  two  parts,  because  of  the  conversations. 
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35.16  The  Graphs 

[Graphs  for  the  example  process.) 

The  graph  for  the  baseline  case  has  six  nodes  arranged  this  way: 

^Contracts  (Node  ACT)  gets  and  receives  the  first  article  from  the  Supplier,  Land- 
Fin  (Bl) 

^Contracts  (ACl)  has  Engineering  (AEl)  test  and  report  on  the  first  article 
^Contracts  (ACl)  notifies  LandFin  (B2)  that  the  design  is  acceptable 
^LandFin  (B2)  accepts  Engineering  (AE2)  in-house  to  monitor  mil-spec  conform¬ 
ance 

^LandFin  (B2)  delivers  an  acceptable  plan  to  Contracts  (AC2) 

The  graph  for  alternatives  #2  and  4  has  five  nodes  arranged  thus: 

^Contracts  (ACl)  asks  Supplier  (Bl)  for  an  acceptable  design  and  indemnification 
plan 

^Contracts  (ACl)  has  Engineering  (AEl)  evaluate  and  report  on  the  plan  and 
design 

^Contracts  (ACl)  sees  a  discrepancy  in  the  plan  and  goes  to  another  company 
(Cl)  to  supplement  the  plan 

4That  company  (Cl)  installs  the  missing  competency  to  the  supplier  (B2) 

4The  supplier  (B2)  reports  back  to  contracts  (ACl)  with  an  acceptable  plan 

If  a  node  has  two  links,  it  is  called  a  two-node,  and  so  on.  If  a  link  is  part  of  a 
two-link  loop,  then  it  is  part  of  what  is  termed  a  two-loop.  Given  this  simple  break¬ 
down,  the  first  graph  has  one  1-node;  three  2-nodes;  and  two  3-nodes;  two  1- 
loops;  and  four  2-loops.  The  second  graph  has  four  2-nodes;  and  one  4-node;  and 
two  2-loops;  and  one  3-loop. 

These  simple  topological  features  are  all  that  is  required  to  extract  our  quanti¬ 
tative  information  about  the  five  features  which  capture  agility. 

35. 1 7  Transaction  Features 

[The  example's  transaction  numbers.} 

We  believe  that  transactions  in  the  enterprise  are  the  fundamental  engine  of  do¬ 
ing  work.  We  further  believe  that  these  five  features  completely  yet  sparsely  (most 
efficiently)  characterize  agility,  the  ability  to  respond  to  change.  Characteristics  of 
the  graphs  give  a  satisfactory  quantitative  metric  for  these  features: 

4Distancei  The  (weighted)  number  of  nodes.  The  weighting  is  by  the  power  of 
each  node  (the  number  of  two-node  is  raised  to  the  power  of  two),  so  the  dis¬ 
tance  (from  zero)  of  the  base  case  is  1 1  -F  22+22+22 -F 33+33=67.  The  distance 
(from  zero)  of  alternatives  #2  and  4  is  22+22+22+22+44=272.  The  relative 
I  distance  between  them  is  272-67=205.  The  time  and  cost  of  adapting  from  a  dis¬ 
tance  of,  say  100,  is  less  in  a  predictable  way  than  the  time  on  cost  of  adapting  a 
distance  of  205. 
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4Time  Delay:  The  (weighted)  total  number  of  loops.  The  weighting  is  similarly  by 
the  power  of  the  loops,  so  the  delay  (from  zero)  of  the  base  case  is 
1 1  +  1 1  +22+22+22+22=18.  The  delay  of  alternatives  #2  and  4  (from  zero)  is 
22+22+33=35.  The  relative  time  delay  is  17.  A  greater  number  is  correlated 
with  a  greater  sum  of  time  and  cost. 

4Moveability:  This  metric  is  a  topology  match  between  the  two  graphs  and  mea¬ 
sures  the  structural  difference  of  the  support  for  communication.  It  is  calculated 
as  the  ratio  of  nodes  that  match  to  baseline  nodes.  The  baseline  case  has  one  1- 
node,  three  2-nodes,  and  two  3-nodes.  Alternatives  #2  and  4  have  four  2-nodes 
and  one  4-node.  Of  these,  three  of  the  six  nodes  can  find  matches  in  the  base 
case,  so  the  moveability  metric  is  50(%).  It’s  a  crude  topological  measure  but  very 
effective:  a  greater  number  indicates  a  greater  match  and  a  lowered  time  and 
cost  to  adjust. 

4Importance:  The  ratio  of  nodes  to  the  total  number  of  nodes  (weighted  sum)  in 
the  contracts  subinfrastrurture  for  the  entire  Virtual  Enterprise  (in  this  case,  the 
supplier  chain),  normalized  by  10,000.  Suppose  that  the  total  number  of  nodes  in 
that  area  is  13,669  for  the  base  case  and  8,085  for  the  alternatives.  Then  the 
importance  of  our  example  in  the  base  case  is  67/13,669x10,000=49,  and  that  of 
the  alternatives  272/8,085x10,000=336,  a  much  higher  importance,  the  differ¬ 
ence  being  287.  The  greater  the  difference  either  way  the  greater  the  time  and 
cost  of  change. 

4Frequency:  Is  calculated  in  the  same  way  as  importance  except  using  weighted 
loops.  Employing  the  same  arithmetic,  the  frequency  distance  metric  between 
the  two  is  1 ,554,  supposing  that  the  base  case’s  loop  sum  are  4,890,  and  that  of 
the  alternatives  is  220.  The  greater  this  number,  the  greater  the  time  and  cost  of 
change. 

35.18  Summing  The  Metrics 

[How  the  component  numbers  are  added.] 

We’ve  given  an  example  of  deriving  metrics  for  one  of  the  small  components 
Into  which  we’ve  decomposed  the  situation.  You’ll  have  many  of  these  for  each  of 
the  three  Legal/Explicit  Infrastructure  domains  under  consideration.  These  will  be 
well-behaved  arithmetically,  and  we  want  to  add  them  according  to  the  impor¬ 
tance  of  that  component  to  the  enterprise.  For  example,  it  may  be  that  the  QA  con¬ 
tracting  area  is  expected  to  carry  three  times  as  much  weight  in  computing  the 
cost  of  change  than,  say,  the  component  related  to  retraining  document  editors. 

This  relative  weighting  is  one  of  three  important  pieces  of  information  that  the 
strategic  planners  passed  to  you  at  the  beginning  of  this  exercise.  They  derived 
that  information  from  simulation  exercises  using  dynamic  forms  of  the  same  met¬ 
rics.  The  three  insights  they  passed  to  you  were: 

^  ^The  relative  importance  among  the  components  of  the  enterprise 

*The  breakdown  of  time  and  cost.  You’ll  have  created  graphs  which  relate  the 
five  features  to  relative  agility.  Your  planners  will  correlate  the  function  you 
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derive  to  the  breakdown  between  time  and  cost,  because  that  relationship  is  a 
matter  of  strategic  priorities. 

^Finally,  they’ll  have  given  you  the  probabilities  to  assign  to  each  of  the  alterna¬ 
tives  so  that  you  can  weight  how  important  agility  for  the  composite  fins  is  com¬ 
pared  to  the  metal  fins  and  the  composite  nozzle.  We’ve  already  noted  that  those 
probabilities  are:  20%  for  the  nozzle,  50%  for  the  composite  fins,  and  30%  for  the 
metal  fins  in  absolute  terms,  but  each  of  these  probabilities  is  time-related. 
Everything  changes,  for  instance,  once  the  deadline  for  selecting  the  nozzle 
passes  at  minus  200  days. 

Alternatively,  you  can  get  the  same  information  from  a  large  robust  Case  Base 
on  collected  calibrated  agility  case  studies.  The  Agility  Forum  has  such  a  case  base 
planned. 

You  are  now  able  to  perform  several  simple  arithmetic  calculations: 

^You  apply  the  time  and  cost  functions  to  break  your  many  component  numbers 
into  their  time  and  cost  equivalents 

^You  use  the  weighting  function  to  sum  all  of  the  components  for  each  alterna¬ 
tive 

On  those  totaled  time  and  cost  curves,  you  locate  your  agility  bogey.  We  use  the 
horizontal  axis  for  this. 

What  you  have  now  is  a  total  time  and  cost  of  change  for  each  of  the  four  alter¬ 
natives,  multiplied  by  however  many  candidate  companies  you  have  (combinations 
of  companies  in  the  cases  of  alternatives  #3  and  4).  But  you  are  not  finished  yet! 
It’s  not  enough  to  go  with  the  candidates  and  alternatives  that  offer  the  lowest 
cost  of  change  if  their  product  cost  is  high.  So  you  now  get  to  add  your  agility  time 
and  cost  of  change  with  separately  derived  time  and  cost  metrics  of  their  basic 
products  and  services. 

And,  at  last,  you  weight  the  costs  by  the  20, 30  and  50%  weighting  for  possibil¬ 
ities  that  you  are  given  and  you  have  indications  for  the  lowest  cost  design  of  a 
supplier  chain  under  the  engineered  conditions  of  change. 
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36  Case  Study  Setup 

jHere  we  describe  the  case  study.] 

We  developed  the  practical  (and  the  alternate)  scenario  to  better  understand 
the  target  application  of  the  sponsors,  namely  the  defense  manufacturing  enter¬ 
prise,  specifically  in  aerospace  systems.  We  also  needed  a  context  for  a  case  study. 

Our  project  did  not  call  for  a  pilot  project  in  this  phase,  one  in  which  tens  of  mil¬ 
lions  hang  in  the  balance,  ideally  with  a  calibrating  base  case.  But  we  did  want  to 
walk  through  a  real  situation  to  test  the  ideas.  During  the  course  of  the  project, 
we  were  reviewed  by  many  enterprises,  who  reported  back  high  confidence  that 
the  method  was  valid,  that  is  to  say,  the  metrics  would  work.  Also  reported  back 
was  confidence  in  the  merits,  the  financial  benefits,  of  agility  in  certain  common 
situations. 

Where  we  were  questioned  was  on  the  cost  of  applying  the  metrics.  Managers 
have  been  burned  before:  they  spend  so  much  effort  and  resources  on  determining 
what  they  should  do  that  they  cannot  afford  to  do  it.  We  would  have  to  determine 
how  much  this  would  cost  in  a  typical  scenario.  In  fact,  if  the  cost  were  not  man¬ 
ageable,  the  method  itself  would  be  too  ponderous  and  could  not  be  used  itself 
agily. 

So  we  set  up  a  case  study  with  the  following  characteristics: 

^focused  on  the  supply  chain,  assuming  practices  current  or  possible  without 
presuming  unrealistic  change  in  acquisition  law; 

^centered  on  problems  of  a  real  tactical  missile  manufacturer  as  defined  by  the 
DARPA  sponsored  Affordable  Multi  Missile  Manufacturing  (AM3)  program; 
^audited  by  an  third  party  experienced  in  enterprise  engineering,  the  Aerospace 
Agile  Manufacturing  Research  Center;  and 

^devised  to  evaluate  the  cost  of  applying  the  metrics  in  a  practical  case. 

36.1  A  Component  in  the  Case  Study 

|We  assume  a  High  Concept  description  of  a  missile.) 

Did  Morita  have  it  right?  Is  Hollywood  an  exemplar  of  the  new  way  of  building 
organizations  which  are  especially  attuned  to  customer’s  needs,  even  more  deeply 
than  they  themselves  know?  Is  this  extractable  from  the  exotic  movie  sector  and 
applicable  to  the  primarily  high-value  manufacturing  domains  which  concern  us  in 
the  agility  community?  Is  this  agility? 

With  due  regard  to  the  limits  of  pressing  analogies  too  far.  We're  inclined  to 
think  so,  and  have  framed  our  Defense  Case  Study  in  the  context  of  a  (fictitious) 
High  Concept  enterprise. 

The  chain  of  logic/chain  of  events  we  tentatively  propose  to  follow  is: 

^Start  with  a  succinct  problem  statement,  a  High  Concept  for  a  missile,  if  you 
7  will. 

^Use  the  AVE  Reference  Model  to  identify  agents  that  result  from  the  High  Con¬ 
cept.  To  some  extent,  we’ve  explored  these  first  two  steps  in  our  strawman.  But 
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we’ll  go  back  and  define  a  workable  High  Concept  and  test  whether  agents  and 
model  cells  follow  as  a  matter  of  engineering  principle  as  opposed  to  art.  We’ll 
apply  techniques  used  in  the  movie  AVE  where  applicable. 

^Decompose  each  cell  into  a  number  of  transactions  among  agents.  This  is  the 
meat  of  the  Case  Study;  we  hope  to  determine  how  costly  it  is  to  evaluate  agility 
in  a  typical  case,  and  believe  this  step  represents  the  greatest  cost  and  greatest 
unknown.  We  may  be  translating  from  a  model  which  has  the  appropriate  infor¬ 
mation;  we  may  be  supplementing  the  model  to  make  it  adequate;  or  we  may 
have  to  start  virtually  from  scratch.  In  this  case,  we’ll  probably  bypass  a  general 
modeling  method,  and  just  directly  populate  our  simple  utterance  table. 

^These  utterances  will  each  be  expressible  in  the  acton  form  that  we’ve  devised 
under  the  Situation  Theory  work  from  our  two  (so  far)  BASTs.  The  equation  form 
will  be: 

^The  collection  of  actons  which  describe  the  interactions  (utterances)  that 
constitute  a  cell  in  the  AVE  model-  then  those  actons  support  the 
situation  of  the  cell.  Collectively,  the  actons  of  all  the  cells  support  the 
situation  which  is  the  High  Concept;  this  is  the  same  as  saying  that  the 
situations  of  the  cells  (meaning  processes  of  partners  in  the  VE)  support 
the  High  Concept  (meaning  the  specific,  deep  opportunity  in  the  customer 
space  being  addressed). 

In  devising  the  Situation  Theoretic  logic,  we  hope  to  extract  parameters, 
variables  and  constants  with  guidance  from  our  movie  exemplar  if  we  can 
keep  them  engaged.  (This  step  is  dependent  on  cooperation  from  the  AM3 
program  office.)  When  tools  are  built,  such  as  the  Pomegranate  example 
we  are  sketching  out,  they’ll  leverage  this  logic. 

^Then,  of  course,  the  agility  metrics  will  be  calculated,  at  both  the  system  level 
and  for  each  individual  cell.  As  noted  in  the  Tool  Strategy,  we’re  putting  private 
funding  into  creating  a  probably  freeware  openDoc  (also  known  as  Live  Objects) 
container  for  visualizing  these  results. 

^Finally,  the  system-level  agility  metric  will  be  applied  at  the  High  Concept  level 
to  evaluate  the  relative  time  and  costs  of  supporting  the  High  Concept  by  those 
agents  and  strategies. 

36.2  Defense  HC  Issues 

[A  few  issues  related  to  defense  high  concepts.) 

Currently,  missile  product  definition  statements  are  pretty  frozen  and  quantita¬ 
tive  by  the  time  they  get  to  the  prime,  who  relatively  late  in  the  game  responds  by 
assembling  a  team/supply  chain.  The  description  is  of  the  form: 

“give  us  a  thing  that  goes  this  far,  this  fast,  is  this  size,  shape  and 
I  weight,  goes  boom  in  this  way,  and  costs  so  much.” 

A  High  Concept  version  would  be  of  the  type: 

“give  us  the  capability  to  perform  this  mission,  or  counter  this 
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threat.” 

An  agile-requiring  High  Concept  would  add  a  range  of  possible  missions  or 
threats.  Because  it’s  unrealistic  to  expect  a  pure  High  Concept,  we’ll  devise  a  hy¬ 
brid:  given  a  specific  missile  (and  it’s  supply  chain)  how  much  In  time  and  cost  will 
it  take  to  engineer  (or  adapt)  a  supply  chain  to  cover  a  given  range  of  missions  or 
threats. 

36.3  Goals 

(What  we  hope  to  accomplish  in  the  case  study.] 

The  central  purpose  of  the  project  is  to  devise  quantitative,  formal  metrics  that 
an  enterprise  can  use  in  evaluating  the  effectiveness  of  processes  and  agents  In  de¬ 
vising  appropriate  agility  strategies.  We  have  those  metrics,  in  a  simple  first-order 
form,  and  a  more  complex  but  capable  form.  A  tool  strategy  has  been  devised 
which  includes  simple,  low-cost  evaluation  techniques  if  the  process  is  well  mod¬ 
eled. 

(The  tool  strategy  is  based  on  bridging  the  gap  between  this  new  idea  of  dynam¬ 
ic  coupling  among  processes  and  existing  business/process  modeling  tools  to  feed 
simple  and  complex  numerical  business  planning  models.  We  propose  to  do  so  by 
relying  on  the  formal  basis  of  the  metrics  as  mathematical  features  of  logical  pars¬ 
ings  of  process  models  or  their  associated  agents.) 

This  leaves  us  with  a  situation  where  we  know  roughly  the  benefits  of  agility  and 
the  effectiveness  of  the  metrics.  But  we  do  not  know  the  cost  of  getting  informa¬ 
tion  from  the  Virtual  Enterprise  into  the  evaluation  process. 

Therefore,  the  primary  purpose  of  the  Case  Study  is  to  evaluate  the  cost  of  get¬ 
ting  sufficient  information  about  yourself,  your  potential  partners,  the  environ¬ 
ment  and  various  strategies.  If  this  cost  is  high,  agility  becomes  problematic, 
regardless  of  benefits.  Our  application  scenario  is  fairly  mundane:  a  conventional 
supply  chain  (Type  3  AVE),  but  further  restricted  from  novel  practices  by  focusing 
on  defense  manufacturing.  This  Is  seen  as  a  defining  domain:  if  the  costs  of  evalu¬ 
ating  agility  in  conventional,  relatively  staid  environments  is  low,  it  should  be  low¬ 
er  as  agility  strategies  increase. 

Because  running  a  test  Involves  walking  through  all  the  major  steps,  a  secondary 
purpose  of  the  study  is  to  understand  how  an  agility  strategy  is  formed,  and  what 
processes  are  involved.  We  expect  that  all  steps  will  have  to  be  considered,  but  the 
major  attention  will  be  on  identifying  the  key  processes  involved,  why  and  how 
they  affect  each  other  and  the  VE. 

36.4  Application  Domain 

(Characteristics  of  the  scenario.) 

f  The  Case  Study  looks  at  agility  in  building  and  maintaining  a  Supply  Chain  in  the 
U.  S.  tactical  missile  community.  This  domain  has  the  following  characteristics, 
which  would  imply  a  need  for  agility: 
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Figure  36-1  :How  Costly  Would  the  Modeling  Be? 


^The  prime  contraaors  are  consolidating  and  sloughing  off  capability,  creating 
VEs  within  the  primes  at  some  level;  investment  cycles  (changerate)  within  the 
primes  are  being  disrupted.  So  multiple  products  must  be  created  with  the  same 
assets. 

*The  product  is  complex  with  a  very  high  technology  component;  changerate 
(rate  of  change)  of  basic  technologies,  in  both  products  and  processes)  is  high 
and  increasing. 

iThe  Supply  Chain  adds  a  significant  percentage  of  the  product’s  value,  with 
many  niches  of  product  and  process  specialization;  that  supply  base  is  becoming 
less  rich  over  time. 

4The  customers  are  changing:  where  the  U.  S.  military  used  to  be  the  primary 
customer,  now  foreign  sales  are  becoming  more  important. 

^More  variants  and  derivatives  are  required;  product/customer  expectation 
changerate  is  increasing.  The  missions  are  more  unknown. 

4To  an  increasing  degree,  the  product  must  be  integrated  into  larger  systems 
whose  basic  designs  and  integration  strategies  are  not  under  the  control  of  the 
prime  but  which  are  jointly  owned  by  several  peer  primes  and  the  customers. 

In  addition,  the  domain  has  the  following  two  characteristics  which  may  be 
(Unique,  and  which  may  make  the  Case  Study  manageable: 

^The  acquisition  laws  and  regulations  which  govern  the  customer  to  prime,  and 
prime  to  subcontractor  relationships  are  different,  more  limiting,  than  those  in 
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the  civil  sector.  Competitive  pressure  exists,  but  the  mechanics  are  different  than 
conventional  free  market  forces. 

^The  defense  manufacturing  base  in  general  is  often  managed  as  a  strategic 
asset.  The  customer,  DoD,  performs  roles  as  conventional  consumer  of  products, 
specifier  (often  designer)  of  products,  often  controller  of  work  breakdown,  pro¬ 
cesses  and  indemnification,  and  as  occasional  manager  of  strategic  design  and 
production  assets. 


Two  supply  chains:  Conventional  chain  (agility  benefits  the  prime);  DoD 
chain  (agility  benefits  the  nation) 

Figure  36-2:ln  DoD,  the  Customer  is  Often  the  Integrator  of  the  Supply  Chain 


36.5  Participants 

|We  work  with  a  real  missile  prime,  audited  by  the  Automation  and  Robotics  Research  Institute.) 

The  Case  Study  Is  designed  to  support  the  goals  of  the  DARPA-sponsored 
project  for  Affordable  MuItiMissile  Manufacturing  (AM^).  This  project  focuses  pri¬ 
marily  on  the  first  characteristic  noted  above:  the  same  assets  need  to  be  applied 
to  multiple  missile  designs  to  effect  cost  savings.  In  order  to  do  this  properly,  AM^ 
addresses  all  of  the  other  noted  Issues. 

We  focus  on  the  missile  Supply  Chain.  There  are  two  Supply  Chain  views.  The 
first  is  conventional:  an  AM^  prime  and  its  subs.  The  suppliers  themselves  will  not 
be  interviewed  in  the  Case  Study.  In  this  view,  we  will  focus  on  elements  common 
^across  defense  and  civil  sectors. 

The  other  Supply  Chain  view  has  the  DoD  at  the  top.  Here,  two  primes  supply 
components  that  the  customer  integrates  as  if  it  were  in  many  ways  the  prime. 
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This  is  unique  to  the  defense  sector.  In  this  case,  the  AM^  prime  and  another  large 
missile  contractor  are  the  two  primes. 

Although  the  Case  Study  is  not  on  a  specific  system,  there  is  a  real  case  in  which 
these  two  are  collaborating  primes,  supplies  a  missile  and  the  second  missile 
prime  supplies  the  submunition.  The  submunition  is  installed  into  the  missile  by 
the  AM^  prime,  but  it  is  specified  and  acquired  by  the  DoD,  provided  as  Govern¬ 
ment  Furnished  Equipment. 

Sirius-Beta  will  lead  the  effort.  The  Automation  and  Robotics  Research  Institute 
(ARRI)  of  the  University  of  Texas  -  Arlington  will  assist.ARRI  is  a  National  Science 
Foundation  Agile  Manufacturing  Research  Center. 

Creating  an  agility  strategy  and  evaluating  options  against  that  strategy  involve 
some  steps  that  cut  new  ground.  The  Agile  Virtual  Enterprise  Focus  Group,  spon¬ 
sored  by  the  Agility  Forum,  is  an  important  review  and  brainstorming  body.  The 
AVE  Group  is  supplemented  by  the  Metrics  email  list  and  web  site  (also  adminis¬ 
tered  by  the  Agility  Forum. 

36.6  Strategy  Identification 

(The  agility  strategies  one  might  consider] 

Agility  is  the  ability  to  respond  well  to  unexpected  change.  Agility  is  obviously 
beneficial  in  a  domain  like  our  target  domain,  but  devising  an  agility  strategy  is 
non-trivial: 

^Agility  usually  costs  money  which  could  be  put  toward  other  strategic  invest¬ 
ments:  relationships  of  agility  to  other  tactics  needs  to  be  evaluated 

iAgility  in  some  dimensions  counters  agility  in  others,  so  the  general  shape  and 
likelihood  of  the  threat  needs  to  be  identified 

^An  agility  strategy  needs  to  work  in  conjunction  with  other  elements  of  strate¬ 
gies  within  the  VE  (market  dominance,  versus  immediate  profitability  for 
instance) 

^An  agility  strategy  needs  to  leverage  natural  strengths  in  the  current  and  possi¬ 
ble  partners’  collective  and  individual  core  competencies  and  management  phi¬ 
losophies 

As  a  result,  an  agility  strategy  cannot  be  prefabricated  outside  of  the  specific 
context  as  less  promising  techniques  can,  such  as  lean.  One  cannot  escape  the  fact 
that  agility  is  a  strategic  weapon  and  cannot  be  crystallized  outside  of  the  individ¬ 
ual  strategic  context.  For  our  Case  Study,  we’ll  follow  what  we  believe  will  be  a 
common  playbook: 

^Evaluate  the  nature  of  the  change  to  which  we  want  our  missile  Supply  Chain  to 
respond,  in  other  words,  the  kind  of  agility  that  we  want  engineered  into  our  VE 
^Identify  a  few  strategies  that  may  provide  an  agile  response.  For  the  Case  Study, 

'  this  will  be  an  intuitive,  ad  hoc  process  guided  by  the  community.  It  is  this  pro¬ 
cess  for  which  outside  guidance  is  sought,  both  for  the  example  case,  and  for 
general  principles  for  others.  However,  elsewhere  we  have  sketched  out  a  tool 
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strategy  that  could  guide  this  process. 

These  strategies  will  vary  according  to: 

^Different  business  models  for  the  VE 
^Different  agility  processes  and  agents  that  support  the  model 
^Different  partners  (in  this  case,  suppliers)  that  have  better  or  worse 
capabilities  in  those  areas 

As  mentioned,  we’ll  look  at  two  Supply  Chains.  Both  will  consider  the  same 
threat  of  change,  as  listed  above.  But  the  emphasis  will  be  on  combining  design/ 
production  assets  for  many  existing  missiles  (which  should  lower  some  costs  with¬ 
out  agility)  at  the  same  time  lowering  costs  associated  with  introducing  technolo¬ 
gy  for  upgrades;  variants;  and  future  (perhaps  modular)  derivations.  But  the  two 
Supply  Chains  will  weight  values  differently: 

^One  will  be  a  conventional  Supply  Chain  headed  by  a  prime  (The  AM^  prime). 
Presumably,  its  primary  values  to  be  supported  by  agility  will  to  continue  as  a 
healthy  entity  (both  as  a  company  and  a  Supply  Chain)  through  making  profit, 
preserving/building  core  competencies,  and  satisfying  the  customer  (DoD). 

^The  other  is  a  Supply  Chain  starting  with  DoD,  including  the  AM^  prime,  the 
second  prime  and  their  lower-tier  Supply  Chains.  It’s  goals  will  differ,  looking  for 
agility  to  deliver  high  quality  missiles  at  acceptable  cost  while  preserving  a 
robust  capability  to  respond  similarly  in  the  future.  It’s  customers  are  the  war 
fighter  and  Congress  (representing  the  Nation)  in  some  often  conflicting  mix 
which  we  won’t  examine. 

The  presumption  is  that  there  should  be  substantial  overlap  between  these  two 
goal  sets;  maximizing  the  overlap  will  be  an  additional  factor  in  evaluating  agility 
strategies. 

36.7  Suggested  Initial  Constraints 

|Here  we  narrow  down  the  scope  of  what  we'll  model.) 

Fortunately  the  constraints  and  dependencies  of  the  models,  as  well  as  the  fo¬ 
cused  goals  of  the  missile  enterprise,  narrow  the  choices  of  agility  strategies,  and 
consequently  cells  In  the  models  to  investigate.  We  exclude  the  Social/Cultural  In¬ 
frastructure.  We  don’t  know  how  to  deal  with  it,  and  it  is  not  directly  in  the  AM^ 
scope.  Let’s  readily  admit  that  this  makes  the  case  study  less  effective  than  it  could 
be.  (The  Work  and  Technology  Institute  anchors  our  projected  future  work  in  this 
regard.) 

Under  normal  conditions,  the  strategy  would  be  measured  under  a  complex  mix 
of  results,  each  with  its  own  metric.  That  mix  would  include  near-term  profitabili¬ 
ty,  and  long-term  profitability  (stockholder  value,  market  share,  goodwill,  capable 
workforce/increased  core  competencies).  For  the  sake  of  argument  and  simplicity. 
>lets  assume  that  the  lesser  supplier  chain  The  prime/sub  chain)  cares  only  about 
near  term  profitability.  Similarly,  we  simplify  the  goals  of  the  larger  Supply  Chain 
(DoD,  through  primes  to  Supply  Chain)  are  a  straightforward  measure  of  lowest 
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cost  product  (missile  systems)  for  the  next  20  years.  Extending  the  measure  for 
two  decades  includes  considerations  of  responsiveness  and  strategic  capability. 

The  scenarios  are  wholly  fictitious,  invented  for  the  sake  of  simplifying  and  fo¬ 
cusing  the  case  study.  No  relationship  to  companies  or  projects  should  be  drawn, 
the  AM^  prime  and  the  second  prime  are  providing  typical  process  examples  only; 
there  is  no  relationship  between  those  firms  and  the  fictitious  examples  we’ve  cre¬ 
ated. 

36.7.1  Simplifying  the  Model 

(Rationale  for  ignoring  large  areas  of  the  Reference  Model.) 

As  a  first  order  of  scoping,  we  suggest  that  we  reduce  the  model  to  something 
manageable:  the  full  Reference  Model  has  a  potentially  very  large  number  of  cells. 
The  five  phases  of  the  life  cycle  only  give  us  26  subphases.  But  the  infrastructure 
(which  is  a  decomposition  of  the  fabric  of  the  VE)  has  an  arbitrarily  large  number. 
For  illustration  above,  we  note  the  five  most  important  for  each  of  the  subinfra¬ 
structures.  That  alone,  yields  over  1500  cells.  But  we  know  that  only  a  few  cells 
bear  on  any  given  agility  strategy.  So  as  a  first  step,  we  suggest  temporarily  setting 
aside  areas  of  the  model  that  are  unimportant  to  the  Case  Study. 

We’ve  already  noted  that  we  set  aside  two  of  the  four  infrastructures,  Social/Cul- 
tural  and  Information.  In  addition,  we’l!  set  aside  considerations  of  Physical  Laws. 
There  are  sorne  interesting  ways  in  which  physical  laws  bear  on  the  subset  of  agil¬ 
ity  called  flexible  manufacturing,  especially  dealing  with  composites,  exotic  mate¬ 
rials,  and  electronic  devices.  But  they  are  uninteresting  in  the  context  of  agility, 
since  those  processes  are  not  ordinarily  delegated  to  the  Supply  Chain.  So  we  set 
aside  that  division  of  the  Physical  Infrastructure. 

We’ll  also  set  aside  the  subinfrastructure  of  equipment;  and  we  do  this  more  de¬ 
liberately.  There  are  two  reasons:  agility  in  the  Supply  Chain  has  primarily  been 
found  to  be  dominated  by  legal  problems,  cultural  mismatch,  and  lack  of  process 
integration.  Agility  of  equipment  is  pretty  far  down  in  the  food  chain.  We’ve  men¬ 
tioned  this  above,  and  submit  it  as  an  example  of  how  higher  level  infrastructure 
can  govern  those  at  a  lower  level.  The  second  reason  is  a  matter  of  focus.  The  nov¬ 
elty  of  agility,  what  makes  it  different  and  new  is  often  obscured.  Many  believe  it 
has  to  do  with  speed,  or  flexibility,  and  a  prevailing,  but  misguided  definition  fo¬ 
cuses  on  how  quickly  equipment  can  be  reconfigured.  Our  setting  aside  of  equip¬ 
ment  all  together  helps  focus  on  more  Important  dynamics. 

This  means  that  we  will  deal  with  four  subinfrastructures:  (using  our  numbering 
scheme  from  above)  A.  B,  C  and  D.  Each  of  these  has  been  expanded  into  five  pro¬ 
cess  areas.  We  suggest  that  we  select  the  one  from  each  which  is  most  apt  to  an¬ 
chor  an  agility  strategy,  giving  us  four  columns  of  interest  (out  of  the  60  we  started 
with). 

}  For  example,  consider  Group  A,  Business  Processes.  We  suggest  that  of  the  five 
listed,  Ae  Depth  of  Customer  Relationships,  is  the  one  which  we’d  like  to  highlight 
as  being  the  most  likely  among  its  siblings  to  anchor,  or  be  a  major  component  In 
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a  missile  Supply  Chain  agility  strategy.  In  evaluating  among  these  five,  you  have  to 
remember  the  whole  hierarchy.  That  is:  the  group  of  five  all  deal  with  explicit  busi¬ 
ness  processes:  processes  that  have  been  engineered,  are  understood  to  great  ex¬ 
tent;  and  deal  with  how  the  business  operates.  This  includes  who  is  responsible 
for  what,  who  reports  to  whom,  who  makes  decisions  about  what,  and  what  crite¬ 
ria  they  use. 

All  of  these  are  important  to  a  healthy  enterprise  in  general;  any  of  these  could 
be  important  in  an  agility  strategy.  However  some  are  less  important  to  agility  or 
to  the  defense  missile  business,  for  example,  A.  d  Work  Scheduling.  Now  remem¬ 
ber,  we’re  not  talking  about  the  whole  beast  here,  there’s  an  area  (we’ve  called  C) 
that  deals  with  the  area  proper.  This  is  just  the  business  process  support  for  work 
scheduling.  In  the  defense  arena,  there’s  little  control  that  the  prime  has  in  inno¬ 
vating  in  this  area;  the  controlling  processes  are  driven  by  the  customer  through 
contractual  and  funding  restrictions. 

A  similar  disqualifying  property  can  be  found  in  the  business  processes  for  Su¬ 
pervising  Quality.  There’s  not  much  flexibility  an  owner  of  a  defense  Supply  Chain 
has  over  those  business  processes.  A  case  can  be  made  that  there  is  some  oppor¬ 
tunity  to  work  with  Risk/Reward  strategies  in  the  Supply  Chain,  and  that  those  af¬ 
fect  agility.  But  we  believe  that  contract  provisions  are  the  governing  dynamics  and 
not  business  practices,  so  we  bump  Risk/Reward  from  this  list,  and  rank  it  high 
among  the  candidates  for  B. 

As  the  high  value  component  among  these  five,  we  select  business  processes  to 
support  A.  e  Depth  of  Customer  Relations.  This  covers  procedures  to  ensure  that 
appropriate  elements  within  the  VE  are  exposed  to,  understand  and  respond  to 
needs  coming  from  the  customer.  This  is  clearly  at  the  root  of  the  need  for  missile 
agility:  the  need  to  respond  at  low  cost  to  product/process  technology,  mission, 
and  Supply  Chain  infrastructure  changes.  And  it  is  an  area  over  which  missile 
primes  (and  the  DoD)  has  the  option  to  innovate;  change  in  these  business  practic¬ 
es  is  happening  regardless  of  agility,  sometimes  in  an  uncontrolled  fashion. 

So  as  our  key  process  from  A,  we  select  A.d.  In  a  similar  way,  we  select  one  from 
each  of  the  other  four.  From  Group  B,  the  group  dealing  with  laws,  contracts  and 
regulations,  we  select  B.  b.  Risk/Reward  Contracts,  as  we  note  above.  Within  the 
AVE,  partners  can  be  expected  to  respond  well  if  the  risks  and  rewards  are  engi¬ 
neered  for  agility. 

C.  c.  Monitoring  and  Adjusting  the  Work  Breakdown  Structure  is  the  third  lead 
category.  This  is  the  process  that  decides  and  reassigns  who  in  the  VE  does  what. 
In  the  defense  enterprise,  the  WBS  is  a  particularly  unagile  process  control  practice 
as  It  puts  the  customer  in  control  of  the  processes. 

From  the  LogisticsAVarehousing  group,  the  lead  activity  is  D.  a.  VE  Human  Col¬ 
laboration.  This  is  the  infrastructure  component  that  supports  how  individuals 
communicate  (and  otherwise  interact).  Since  agility  revolves  around  trusted 
^agents,  and  the  influence  of  such  agents  is  determined  by  face  time,  this  is  an  es¬ 
sential  infrastructure. 
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36.7.2  Life  Cycle  Selections 

[Rationale  for  narrowing  down  to  a  few  life  cycle  points.) 

In  a  similar  way,  we  simplify  the  Case  Study  by  choosing  one  division  from  each 
of  the  five  major  Life  Cycle  divisions.  From  J.  Opportunity  Identification,  we  select 
i  .3  Targeted  Market:  This  is  a  process  of  active  discovery  and  engagement  with  the 
potential  user,  more  suited  to  the  missile  community  than  the  other,  more  oassive 
functions  in  this  group. 

From  2.  Partner  Selection,  we’ll  focus  on  2.3  Partner  Search  since  we’ll  assume 
that  there  is  no  substantial  prequalification  strategy  or  historical  record  of  perfor¬ 
mance  in  unexperienced  processes.  3.6  Risk/Reward  Strategies  is  the  key  process 
from  group  3,  for  reasons  already  argued  above.  In  this  case,  we’re  talking  about 
a  step  in  forming  the  VE,  based  on  the  process  of  determining  the  approach  to  risk 
and  reward.  In  the  infrastructure,  we’re  talking  about  the  legal  scaffolding  build  to 
support  such  a  strategy. 

Group  4,  VE  Operation  yields  4.1  Performance  Metrics  as  the  primary  target. 
These  are  the  measures  used  in  operation  to  determine  that  each  partner  is  doing 
Its  job.  We  target  this  area  because  in  the  defense  establishment,  it  was  often  the 
case  that  the  customer  intruded  into  this  monitoring  process,  for  example  by  sup¬ 
plying  auditors  and  setting  specifications.  Alternatives  could  yield  greater  agility. 
Finally,  we  settle  on  Identifying  the  Need  to  Change,  process  1  of  group  5.  The  fo¬ 
cus  on  this  is  a  direct  result  of  recent  AVE  Focus  Group  attention  on  trusted  agents. 
An  element  of  the  trust  is  confidence  in  the  ability  to  recognize  the  need  for 
change  in  the  VE. 


1.3  Targeted  Market 

2.3  Partner  Search 
3.6  Risk/Reward  Strategies 
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Table  36-1:  The  Focus  Cells  for  the  Aerospace  Prime 


36.7.3  Agility  Strategies 

(Four  different  strategies  that  may  be  pursued,  with  example  processes.] 

We’ve  abstracted  out  some  high  value  elements  of  our  model  for  the  sake  of  the 
Case  Study.  Now  we  have  four  infrastructure  columns: 

^A.  e  Depth  of  Customer  Relations 
^B,  b.  Risk/Reward  Contracts 

4C.  c.  Monitoring  and  Adjusting  the  Work  Breakdown  Structure 
^D.  a.  VE  Human  Collaboration 

And  five  Life  Cycle  processes: 

4 1 .3  Targeted  Market 

^2.3  Partner  Search 

^3.6  Risk/Reward  Strategies 

^4.1  Performance  Metrics 

^5.1  Identifying  the  Need  to  Change 

A  total  of  twenty,  high  value  cells  results.  The  meat  of  the  Case  Study  is  to  in¬ 
vestigate  how  difficult,  how  costly  it  is  to  discover  sufficient  information  about 
each  of  those  twenty  cells  to  allow  us  to  compute  our  agility  metrics  (for  each  al¬ 
ternative  for  the  cell).  In  doing  so,  we’ll  be  guided  by  the  following  strawman  agil¬ 
ity  strategies.  We  repeat,  the  strategies  are  wholly  synthetic,  unrelated  to  actual 
strategies  within  the  second  prime  and  the  AM^  prime. 
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36.7.3.1  DoD’s  Agility  Strategy  1  (I) 

Let’s  suppose  that  DoD  wants  to  lower  the  cost  of  missiles,  and  it  has  deter- 
rnined  that:  high  costs  are  due  to  specialization.  A  major  symptom  is  the  one  mis¬ 
sile  type,  one  plant/design  team/Supply  Chain  problem  that  is  apparent.  But 
underlying  this  is  the  high  cost  of  moving  across  business  practice  boundaries 
once  a  project  is  rolling,  affecting  the  ability  to  mix  Supply  Chain  expertise  and 
processes.  This  also  prevents  DoD  from  inserting  technology  into  existing  prod¬ 
ucts  for  upgrades,  variants  and  special  editions. 

DoD  might  pursue  an  agility  strategy  that  builds  a  Supply  Chain  that  has  trusted, 
empowered  agents  in  key  positions.  These  agents  are  particularly  Integrated  Into 
DoD  s  systems  for  determining  need,  or  making  cost/performance  trade-offs.  They 
would  be  able  to  bring  information  to  the  table  about  the  need  to  adapt  processes 
and  the  cost  of  adaptation. 

This  is  a  specific  agility  strategy  that  DoD  as  the  owner  of  a  Supply  Chain  might 
devise.  A  way  to  support  this  strategy  would  be  to  focus  on  cell  A.  e  (Business  Prac¬ 
tice  Infrastructure  to  Support  Depth  of  Customer  Relations  in  the  Supply  Chain) 
and  5.1  (Identifying  the  Need  to  Reconfigure  the  Supply  Chain).  This  is  the  set  of 
processes  which  establishes  trusted  agents  for  change  by  both  providing  them 
with  insights/feedback  to  the  customer’s  needs  and  the  wisdom/ability  to  make  ap¬ 
propriate  changes  in  the  Supply  Chain. 

You  could  put  together  a  support  strategy  in  which  these  cells  that  dominate  in 
their  support: 

4A.e/  4.1 :  Business  practice  infrastructure  that  bases  the  way  the  Supply  Chain  is 
measured  in  its  performance  on  how  well  the  listen  to  and  respond  to  the  needs 
of  DoD. 

^B.b/  3.6:  Contractual  infrastructure  that  supports  the  above  by  building  appro¬ 
priate  risk  and  reward  strategies  into  the  Supply  Chain 

^C.^1.3:  Infrastructure  which  identifies  the  mapping  of  processes  in  the  Supply 
Chain  to  specific  product  goals  in  DoD. 

^D.a/2.3:  Infrastructure  which  provides  for  sufficient  collaboration  among  agents 
in  the  existing  and  potential  Supply  Chain. 

36.7.3.2  DoD’s  Agility  Strategy  2  (II) 

Alternatively,  DoD  may  wish  to  optimize  the  Supply  Chain  to  address  a  specific 
shortcoming  in  its  contracting  practices  that  has  hampered  agility  (and  had  other 
deleterious  effects).  Weapons  In  general  have  veiy  high  performance  require¬ 
ments.  In  the  past,  DoD  has  intrusively  monitored  the  performer  and  the  process 
to  assure  high  quality  In  this  regard.  But  DoD  could  look  for  other  ways  of  manag¬ 
ing  this  performance  equation. 

So  DoD  might  be  interested  in  an  agility  strategy  that  lets  the  Supply  Chain  flex¬ 
ibly  work  out  who  does  what,  so  long  as  there  are  adequate  performance  metrics 
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that  travel  with  the  work  package,  and  those  performance  metrics  are  directly 
linked  to  system-level  performance  goals  monitored  and  changed  by  the  customer. 

So  instead  of  having  to  look  into  every  component  process  when  a  system-level 
specification  is  examined,  the  supply-chain  is  self-correcting  to  parcel  out  the  work 
and  measure  performers  appropriately. 

The  basic  cell  in  this  case  is  C.c/4.1,  infrastructure  which  parses  the  complex 
product,  the  tasks  that  need  to  be  performed,  and  the  measures  that  guarantee 
quality  to  respond  to  DoD  s  needs  without  requiring  DoD’s  intervention  This 
strategy  would  be  supported  by: 

^A.^.6:  Business  practice  infrastructure  that  ties  how  risks  and  rewards  are 
monitored  to  directly  support  DoD’s  needs  for  the  system. 

^B.b/5.1:  Contract  clauses  that  rewards  suppliers  who  recognize  and  instigate 
change  that  benefits  DoD,  but  adversely  impacts  their  conventional  business  role. 
^C.c/2.3:  Infrastruaure  which  identifies  (and  perhaps  prequalifies)  the  skills  and 
qualities  needed  in  suppliers  to  support  this  agility  strategy. 

^D.a/1.3:  Infrastructure  which  supports  a  continuous  collaborative  structure 
between  the  key  elements  within  the  Supply  Chain  and  the  DoD  customer  to 
assure  that  there  is  a  good  mapping  from  the  DoD’s  system-level  performance 
goals  to  the  detailed  workpackage  measures. 


36.7.3.3  Prime’s  Strategy  1  (111) 

Alternatively  or  coincidentally,  the  prime  contractor  will  have  need  for  agilitv 
strategies  which  benefits  it  as  a  business.  We’ll  explore  two  examples  of  this. 

Suppose  that  the  prime,  missile  contractor  understands  that  essentially  all  new 
rnissile  business  will  be  based  on  current  designs  in  some  way.  That  means  exten¬ 
sions  of  current  processes  and  Supply  Chains.  Also  suppose  that  their  fasted  grow¬ 
ing  areas  of  opportunity  are  foreign  sales,  and  each  foreign  customer  has  some 
special  tweak  it  needs. 

You  want  a  supplier  chain  that  is  built  to  agily  respond  to  this  large  class  of  dif¬ 
ferent  and  changing  opportunities  as  a  simple  business  matter. 

This  strategy  will  be  built  on  cell  B.b/1 .3,  which  concerns  contractual  infrastruc¬ 
ture  support  within  the  Supply  Chain  so  that  each  supplier  is  rewarded  for  helping 
you  identify  and  address  opportunities  by  modifyin^updating  internal  processes 
The  supplier  may  be  rewarded  even  if  the  opportunity  doesn’t  mention  conven¬ 
tional  business  sense. 

Note  that  this  is  different  than  what  we  noted  above,  where  suppliers  get  re¬ 
warded  for  benefiting  the  (existing)  customer.  (Here  agility  benefits  the  prime  over 
a  customer  if  there  is  a  conflict.) 

,^^In  addition  to  the  primary  cell,  a  strategy  along  these  lines  might  be  supported 
^A.e/2.3:  Business  practice  infrastructure  to  continually  identify  partners  who 
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can  help  identify  and  evaluate  opportunities  by  understanding  (potential)  cus¬ 
tomers 

*B.b/4.1:  Contractual  infrastructure  which  harmonizes  performance  metrics  with 
new  business  rewards,  thus  combining  agile  new  business  identification  with 
agile  manufacturing. 

4C.C/3.6:  A  work  breakdown  process  that  gives  each  partner  reward  for  seeking 
new  opportunities,  even  those  quite  different  from  the  current  product  type. 
^D.^.l :  Infrastructure  that  builds  a  team  among  key  agents  in  the  Supply  Chain 
to  share  intelligence  on  and  collaborate  to  reach  new  opportunities. 

36.7.3.4  Prime’s  Strategy  2  (IV) 

Finally,  another  different  example  could  be  described  among  the  many  that  a 
prime  may  pursue.  This  one  relies  on  D.a/3.6  to  set  up  a  collaborative  infrastruc¬ 
ture  so  that  trust  is  built  among  the  key  players  among  the  partners.  The  rewards 
benefit  the  players  in  a  more  self-organizing  way  than  the  example  above.  There 
the  Supply  Cham  is  engineered  to  benefit  the  prime.  Here,  the  partnership  is  engi- 
rieered  to  help  each  member  (including  the  prime).  Since  this  is  a  opportunity- 
seeking  strategy,  rather  than  a  partner-seeking  one,  it  tends  to  a  Type  4. 

This  agility  strategy  is  supported  by: 

^A.e/1 .3:  Business  praaices  that  encourage  players  deep  in  the  Supply  Base  to 
probe  the  market,  alert  for  opportunities  for  the  VE,  perhaps  representing  same. 
^B.b/2.3:  Contract  support  for  a  partner  to  benefit  if  it  finds  a  way  to  identify 
new  partners,  even  competitors,  if  it  will  bring  the  aggregate  closer  to  new,  good 
business.  ’  ® 

^C.c/5.1:  Provision  for  a  partner  in  the  Supply  Chain  who  is  not  biased  to  the 
prime,  and  who  equally  represents  all  of  the  partners  in  seeking  new  opportuni¬ 
ties.  This  partner  presumably  does  nothing  else. 

^D.a/4.1 :  Operating  metrics  which  track  and  reward  the  quality  of  support  to  sus¬ 
taining  the  VE  above  and  beyond  merely  producing  goods  and  services. 

36.8  Examining  the  Cells 

iSummarizing  the  strategies  and  focus  cells.) 

To  summarize,  we  have  identified  four  example  agility  strategies,  each  with  a 
different  set  of  goals,  but  all  using  general  assumptions  of  the  missile  community. 
Two  benefit  DoD,  as  head  of  a  Supply  Chain,  and  two  provide  presumably  sliehtiv 
different  benefit  to  a  missile  prime.  These  are  briefly:  ^ 

^1.  Lowering  the  cost  of  missiles  by  relaxing  the  costs  of  adjusting  the  Supply 
Chain  to  respond  to  change  in  technology  or  requirements. 

'  411.  Lowering  the  costs  of  missiles  by  decentralizing  the  monitoring  of  product 

workpackage  processes. 

4111.  Responding  to  new  foreign  and  derivative  US  opportunities  by  changing/ 
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extending  core  competencies  within  the  Supply  Chain. 

41V.  Responding  to  new  foreign  and  derivative  US  opportunities  by  leveraging 
customer-inspired  enhanced  process  improvements  by  the  Supply  Chain  func¬ 
tioning  as  a  bidding  collective. 


plan  is  for  the  second  prime  to  help  us  examine  the  cost  of  evalu¬ 
ating  the  cells  related  to  the  DoD  strategies,  and  for  the  AM^  prime  to  help  with 
those  related  to  the  prime. 
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37  Case  Study  Ouestionnairp 

firnlll"*  questionnaire  initially  given  to  the  prime  and  a  number  of  cooperating 

37.1  Background 

Oust  the  short  version  is  reproduced  here.) 

This  section  reproduces  the  short  version  of  the  questionnaire  that  was  used  in 
the  ta^t  aerospace  prime.  It  was  also  widely  circulated  via  the  web  to  other 
firms.  Those  other,  voluntary  responses  provided  validating  information  for  the 
conclusions  we  reached. 

37.1.1  Larger  Context 

[As  background,  the  approach  is  reviewed.) 

The  Case  Study  focuses  on  one  step  in  a  several-step  process  an  enterprise 
might  employ  in  engineering  an  agile  system. 

^1)  Identifying  the  threat.  An  agility  strategy  depends  on  what  type  of  unex¬ 
pected  change  you  intend  to  counter.  Agility  in  one  direction  may  not  contribute, 
may  even  counteract,  agility  in  another.  While  not  In  the  MAVE  project’s  scope,  ’ 

we’ve  also  studied  how  one  sector,  the  movie  industry,  tracks  trends  to  extrapo¬ 
late  change. 

An  example  threat  for  a  DoD  acquisition  manager  would  be  to  lower  the  cost  of  a 
spectrum  of  future  variants  of  existing  missiles  without  knowing  much  about 
what  new  technologies  will  be  available,  or  mew  mission  profiles  may  appear. 
Perhaps  the  general  shape  of  the  change  is  known.  From  a  missile  prime  contrac¬ 
tor  s  perspective,  this  defines  a  market  opportunity. 

^2)  Devising  a  high  level  strategy.  Decisionmakers  responsible  for  the  VE  will 
strategize  on  the  bet  approach  to  take.  In  the  probably  better  cases,  each  strate¬ 
gic  response  will  be  tailored  to  the  stimulus  rather  than  simply  being  inherited, 
for  example  from  the  prime’s  global  strategy. 

just  one  example  among  many  high  level  strategies  may  be  to  outsource  all  but  a 
few  key  processes,  having  a  spearum  of  subcontractor  possibilities  from  standby 
suppliers,  prequalified  suppliers  and  have  an  open  search-and-bond  process  for 
new  suppliers.  Further,  you  may  have  operations  controlled  by  management 
teams  from  all  partners  as  well  as  representatives  of  the  customer.  But  many 
other  strategies  may  apply. 

3)  Looking  at  specific  processes.  Having  a  strawman  high  level  strategy,  you’ll  need 
to  evaluate  it  and  or  implement  it  through  a  number  of  low-level,  process-ori¬ 
ented  tactics.  Implementing  the  strategy  will  focus  on  novelty  and/or  excellence 
in  a  few  specific  processes  specific  to  both  a  prime  (VE  organizer)  and  the  suppli¬ 
ers  (partners).  You  will  be  faced  with  different  combinations  of  processes  which 
can  implement  the  strategy. 

^4)  Selecting  specific  processes  to  implement  the  strategy  by  evaluating  the  rela- 
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tive  cost  (in  time  and  dollars)  of  each  process  and  process  combination  to  provide 
you  the  type  and  level  of  agility  required. 

^5)  Looping  back  to  see  if  Information  about  the  costs  of  the  selected  strategy 
and  newly  appearing  alternatives  change  your  presumptions  of  your  agility  strat¬ 
egy  (loop  to  step  2)  or  your  understanding  of  the  threat  or  opportunity  (loop  to 
step  1). 

The  MAVE  project,  and  the  Case  Study,  is  focused  exclusively  on  tools  and  tech¬ 
nologies  for  step  4,  where  agility  metrics  are  derived  from  specific  detailed  pro¬ 
cesses.  These  processes  can  be  either  candidates  for  an  agility  strategy,  or  your 
current  agility  strategy  which  is  under  review. 

However,  the  MAVE  project  has  looked  at  tools  for  the  other  steps  as  well.  For 
step  1  and  2,  to  initially  speculate  on  the  shape  of  the  threat/opportunity  and  re¬ 
sponse,  Sandia  National  Labs,  The  Automation  and  Robotics  Research  Institute, 
Sirius-Beta  and  the  AVE  Focus  Group  developed  a  structured  controversy  brain¬ 
storming  method  which  seems  to  be  effective.  For  step  3,  the  AVE  Focus  Group’s 
Reference  Model  has  been  developed.  This  Is  outlined  below.  The  metrics  depend 
on  this  breakdown.  Also,  a  specific  prototype  tool.  Pomegranate,  is  being  fleshed 
out  to  aid  in  the  evaluation  of  processes  and  the  exploration  of  agile  alternatives. 

The  looping  back  of  step  5  could  be  done  in  a  few  ways.  One  intent  may  be  to 
use  system-level  agility  insights  to  interact  with  other  conventional  metrics  (prod¬ 
uct  cost,  response  time,  appropriate  customer-driven  quality).  Mashed  Potatoes  is 
the  tool  which  is  being  prototyped  for  this  need.  Users  will  be  planners  with  exist¬ 
ing  skills.  A  spreadsheet-like  format  is  used,  relying  on  the  AVE  Model. 

But  you  may  want  to  loop  back  using  a  tool  which  looks  for  patterns  in  past  cas¬ 
es  or  stored  simulations.  New  skills  would  be  required  for  such  a  tool.  Turnip  is  an 
example  we’ve  prototyped.  A  document  on  the  tool  strategy  is  at  the  web  site. 

For  the  case  study,  we  assume  that  the  situation  is  one  of  primes  looking  to 
maximize  new  opportunities  by  engineering  an  agile  supply  chain,  managing  that 
agility  (as  well  as  the  supply  chain  of  course)  and  refining  internal  core  competen¬ 
cies. 

37.1.2  The  AVE  Focus  Group  Reference  Model 

(The  Reference  Model  is  reviewed.) 

The  questionnaire  references  a  model  developed  by  the  Agile  Virtual  Enterprise 
Focus  Group,  created  with  the  intent  of  providing  a  best  parsing  of  the  processes 
and  components  of  a  virtual  enterprise.  The  model  is  presented  in  the  form  of  a 
table. 

One  dimension  of  the  table  breaks  down  the  processes  of  instigating,  devising, 
forming,  operating  and  dissolving  a  VE.  Each  step  requires  decisions,  the  primary 
defining  rule  for  inclusion.  A  best  agile  practices  study  conducted  by  the  group  val¬ 
idated  the  general  approach  and  refined  the  breakdowns. 

The  other  dimension  of  the  table  concerns  decomposition  of  the  VE’s  infrastruc¬ 
ture.  Since  the  creation  of  a  VE  is  the  creation  of  infrastructure  of  different  kinds. 
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this  breakdown  is  fundamental.  Some  of  the  infrastructure  categories  are  better 
understood  or  relevant  to  the  types  of  situations  of  interest,  so  are  better  articu- 
lated  than  others.  Infrastructures  that  are  most  of  interest  for  the  Case  Study  are 
those  dealing  with  business  practices,  contracts,  workflow,  and  logistics. 

The  table  defines  cells  that  provide  a  granularity  of  processes  that  is  helpful  for 
agility  planning.  Certain  cells  could  form  the  basis  for  an  agility  strategy,  in  which 
case  others  may  be  important  in  providing  support.  Still  other  cells  may  require 
attention  in  not  negating  the  strategy.  Examples  that  we  have  examined  indicate 
that  a  robust  agility  strategy  may  address  only  a  dozen  or  fewer  cells  in  the  model. 

Employment  of  the  agility  metrics  depends  on  the  AVE  Focus  Group  model  for 
a  clear  definition  of  processes,  a  standard  granularity  of  those  processes,  and  a  wav 
of  representing  how  each  part  contributes  to  the  whole. 


37.1 .3  The  Case  Study  Method 

[How  the  case  study  is  pursued.) 

The  Case  Study  is  one  task  under  a  DoD  research  contract.  Results  from  the  Case 
btudj^s)  will  be  analyzed  by  the  Automation  and  Robotics  Research  Institute  (ARRI) 
and  the  AVE  Focus  Group.  Perhaps  elements  will  also  be  discussed  on  the  email 
list.  The  results  will  be  posted  at  the  web  site  and  included  in  the  publicly  available 
hnal  report.  Generally,  the  process  of  analysis  and  struggling  with  issues  is  an  open 

However,  the  project  has  a  well  tested,  and  long  history  of  protecting  the  sourc¬ 
es  of  information  and  insight.  The  presumption  in  working  with  the  questionnaires 
and  su^equent  discussions  is  that  company-specific  information  will  be  obscured 
to  a  sufficient  level  of  comfort,  to  be  defined  by  the  source  company. 

We  intend,  in  the  full  write-up,  to  wrap  the  Case  Study  in  discussion  of  an  exam¬ 
ple  Steps  other  than  four  will  use  a  clearly  fictitious  context,  based  on  a  generic 
defense  aerospace  need.  In  order  to  ensure  that  none  of  the  relevant  insights  are 
lost,  we  will  seek  the  source  company’s  certification  that  the  results  are  corrert  in 
elements  that  matter,  and  that  they  reflect  the  state  of  the  industry  as  best  thev 
know.  Non-disclosure  agreements  can  be  executed.  ^ 

Incidentally,  we  do  intend  to  release  the  questionnaire  generally,  without  fee 
for  companies  to  use.  Feedback  where  volunteered  from  these  sources  will  be  in¬ 
corporated.  However,  this  is  not  an  instrument  where  we  seek  large  numbers  of 
respondents  in  order  to  perform  statistical  analyses.  Indeed,  we  expect  to  bypass 
the  actual  writing  of  individual  responses  where  verbal  dialog  is  more  efficient. 

Finally,  helping  the  project  with  the  questionnaire  is  presumed  to  be  beneficial 
to  a  company  in  learning  about  our  approach  to  engineering  agile  systems.  The 
normal  benefit  that  goes  with  self-examination  in  a  new  light  will  also  result  But 
there  is  no  consulting  or  advisory  feedback  planned.  The  ARRI  can  provide  that  at 
presumably  modest  cost,  outside  of  the  project.  Or  consultants  may  use  the  tools 
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37.2  Questions  (with  Explanation) 

(The  questions,  with  extended  explanation.) 


37.2.1  Structure 

|How  the  questions  are  struaured.j 

There  are  primary  groups  of  questions.  The  second  group  contains  the  $64 
questions,  with  the  first  providing  context.  In  each  case,  the  normal  form  is: 

“do  you  have  a  such-and-such". 

followed  by  questions  that  presumed  that  you  did.  We  expect  that  in  manv 
probably  most,  cases  you  will  not  have  a  such-and-such.  But  please  go  on  to  answer 

the  questions  as  //you  did  have  a  such-and-such,  presuming  that  you  can  reason¬ 
ably  imagine  having  one. 

The  questions  are  written  as  if  they  were  to  be  repeated  for  each  of  the  twenty 
ma^ny  of  t^ese^^  model.  However,  your  responses  are  likely  to  be  identical  for 

We  expect  that  the  easiest  way  to  respond  to  all  questions  will  be  verbal  rather 
than  written.  So  if  you  are  encountering  this  questionnaire  cold,  so  to  speak  and 
you  ^nt  such  an  interaction,  please  contact  Ted  Goranson  (757/426-6704  ’ 

fo?  to  dialog  (817/272-2495,  jrogers@arri.uta.edu)  to  arrange 

37.2.2  Group  1:  Existence  of  Controlled  Processes 

|0f  the  twenty  cells,  do  you  have  some  to  which  you  currently  assign  resources?! 

Please  review  the  AVE  Focus  Group  Model.  We’ve  selected  twenty  example  cells 
which,  based  on  initial  intemews,  appear  to  be  cogent  to  conventional  prime-sup¬ 
plier  relationships  in  the  defense  aerospace  sector.  Use  these  or  a  self-seWed  set 
that  IS  more  cogent  to  your  business. 

We  expect  that  there  will  be  many  cells  for  which  there  is  no  real  process  even 
in  agile  enterprises.  A  real  process  is  one  to  which  costs  are  allocated.  What  cells 
do  you  have  real  processes  to  support? 

Probably  there  are  a  number  of  cells  for  which  you  do  not  have  processes  but 
tor  which  you  can  easily  imagine  a  process  set  up  and  supported  by  your  company 
and  suppliers.  What  cells  fall  into  this  category?  "  ^ 

Ta'JI- '  u  "f  ‘if  enterprise  would  not  naturally  support 

as  It  IS.  Which  of  these  fall  into  the  following  categories: 

^It’s  too  hard;  we  know  enough  about  how  to  do  it  to  know  it’s  unrealistically 
difficult;  ^ 

^It’s  too  expensive;  we  know  how  to  do  it,  but  it  just  doesn’t  seem  worth  it; 

^It’s  too  alien;  we  haven’t  an  idea  what  you’re  talking  about; 

^It’s  contrary  to  our  corporate  culture  or  strategy;  getting  into  this  process  con¬ 
travenes  or  negates  some  other  cell  or  philosophy  on  which  my  company 
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depends; 

^There’s  some  other  barrier  (for  example  a  regulation). 

Next,  presume  that  you  have  one  or  more  candidate  processes  in  mind  for  each 
of  the  cells.  If  you  were  evaluating  an  existing  supply  chain’s  agility,  these  would 
have  to  be  existing  processes.  If  you  were  evaluating  various  options  for  a  foture, 
engineered  supply  chain,  they  could  be  notions,  but  notions  of  realistic  processes. 

However,  we’d  like  these  processes  to  be  engineered  processes.  In  addition  to 
consuming  costs,  a  requirement  from  above,  they  should  each  require  management 
attention,  they  would  be  controlled  processes. 

For  the  processes  from  above,  are  they  planned,  engineered,  and  controlled  to 
achieve  best  effect,  regardless  of  agility?  Or  are  they  largely  default  processes, 
evolving  of  themselves.  If  they  re  not  engineered,  can  you  imagine  them  to  be  so? 

37.2.3  Group  2:  Representation  of  Processes 

[Section  asks  how  the  processes  are  currently  represented.) 


37.2.3.1  Review 

Let’s  review.  What  you  should  have  now  is: 

threat  or  opportunity.  The  suggested  opportunity  for  the  missile  prime  is  how 
to  fill  the  customers’  need  for  missile  variants  while  only  generally  knowing  the 
nature  of  changes  in  missions  and  technology. 

^One  or  more  themes  for  your  strategy;  you  may  call  these  high  level  or  general 
strategies.  Such  strategies  are  based  on  your  strengths,  on  business  strengths 
and  goals,  and  on  specific  peculiarities  of  the  situation. 

breakdown  of  each  strategy  into  a  small  collection  of  relevant  cells  of  the  AVE 
Focus  Group  Model. 

^Possibly  several  candidate  processes  for  some  of  the  cells. 

There  are  many  ways  to  use  the  metrics.  In  this  example,  we  assume  that  you 
will  be  using  the  metrics  to  evaluate  both: 

^Which  processes  being  considered  for  a  cell  are  the  most  agile;  and, 

^Which  small  combination  of  populated  cells  provide  the  most  effective  agility 
strategy. 

37.2.3.2  The  Leap 

The  main  task  in  using  the  metrics  is  to  make  a  transition  In  how  these  process¬ 
es  are  represented.  We  need  to  get  from  however  they  are  currently  represented 
and  understood,  to  a  specific  representation  we  need  to  evaluate  the  metric.  The 
►good  news  is  that  by  working  with  the  AVE  Reference  Model,  as  you  have  to  iden¬ 
tify  processes  and  cells,  three  hard  issues  have  been  addressed. 

i Processes  with  different  underlying  mechanics  have  been  separated;  the  under- 
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lying  mechanics  of  what  goes  on  in,  say  the  contract  universe,  is  different  than 
those  in  the  physical  world.  Breaking  things  down  by  our  infrastructure  columns 
takes  care  of  that. 

^Each  process  must  support  a  decision.  We  are  engineering  the  control  structure 
of  creating  and  operating  agile  enterprises.  Processes  only  have  meaning  where 
they  affect  this  control.  Working  with  the  Model’s  rows  takes  care  of  that. 

4We  need  to  have  a  standard  level  of  granularity  for  each  of  the  processes  we 
start  with.  The  cells  provide  that  armature. 

So,  although  the  Model  may  have  broken  things  down  differently  than  you 
might  otherwise  do  in  your  organization,  it’s  been  for  a  purpose.  Please  consider 
the  cost  and  difficulty  of  breaking  the  processes  down  in  this  way,  the  Model’s 
way,  as  you  answer  the  questions. 

We  need  to  go  from  however  you  understand  your  process  to  an  act-based  un¬ 
derstanding  of  a  few  elements  of  that  process. 

37.2.3.3  General  Needs 

Information  Theory  has  a  well  developed  formal  mathematics  of  information- 
based  processes.  In  particular,  there  are  notions  of  complexity  which  can  be  de¬ 
rived  and  analyzed.  Some  of  these  complexity  metrics  correlate  well  to  a  process’s 
ability  to  adapt  to  changes  in  adjacent  processes.  Our  metrics  leverage  these  re¬ 
sults. 

We  need  to  translate  some  elements  of  the  business  processes  into  these  infor¬ 
mation-theoretic  types  of  processes.  The  good  news  is: 

4We  need  only  a  small  portion  of  the  information  captured  in  a  typical  business 
modeling  or  engineering  exercise. 

^This  is  generally  the  easiest  information  to  obtain  if  the  process  is  understood. 
It  focuses  more  on  the  structure  of  the  actions  involved  and  less  on  the  details, 
like  what  triggers  the  action  and  how  it  fits  in  sequence.  Also,  we  don’t  care  how 
long  an  action  takes. 

The  bad  news  is  that  the  processes  in  this  case  involve  suppliers.  Suppliers  are 
used  to  being  asked  about  quantities,  times,  cost  and  quality.  In  rare  instances, 
they  might  be  asked  about  the  effectiveness  of  their  process.  But  they  are  not  used 
to  being  asked  questions  about  the  structure  of  their  internal  processes.  A  signifi¬ 
cant  percentage  of  the  cost  of  the  metrics  may  revolve  around  Just  getting  the  sup¬ 
pliers  to  understand  the  question. 

Each  process  from  the  Model’s  cells  gets  decomposed  into  its  set  of  communi¬ 
cative  acts.  Much  information  will  be  discarded  if  this  information  is  being  taken 
from  a  business  model  (such  as  those  supported  by  Intelligent  Systems  Technology 
Inc.  or  Knowledge  Based  Systems  Inc.  or  Intelligent  Systems  Technology  Inc. 

^  Generally  what  we  need  is  who  the  actors  are,  what  they  say.  to  whom,  and  in 
response  to  what  other  acts.  It’s  an  intuitive  representation. 
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37.2.3.4  Specific  Needs 

The  Speech  Act  representation  breaks  a  process  down  into: 

4Actors  and  acts.  The  acts  are  simple  communicative  aas  which  have  a  well- 
known  breakdown.  Non-speech  acts  are  ship  and  pay.  Speech  acts  are  of  two 
types,  solicit:  request  and  question  and  the  second  type,  assert:  inform,  commit, 
and  refuse. 

^Characteristics  of  the  acts.  There  are  four: 

^Responds  to:  every  act  is  prompted  by  an  act  which  precedes  it.  The 
presumption  is  that  all  acts  except  the  first  are  contained  in  the  process. 
4Replies  to:  to  which  act  the  response  is  addressed.  Can  be  different  than 
the  trigger  act. 

4ResoIution  is  the  state  of  closing  an  conversation  internal  to  the  process. 
Some  acts  are  resolved  before  the  process  is  completed. 

^Completion  is  the  state  where  all  conversations  are  resolved  and  the 
process  terminates. 

This  sounds  more  complicated  than  it  is.  In  practice,  the  process  is  simply  who 
says  what  in  response  to  what  and  is  the  type  of  modeling  managers  like  to  do  with 
post-it  notes.  For  the  metrics,  it’s  not  important  to  know  what  type  of  act  is  what, 
nor  what  any  of  the  characteristics  are.  But  they  are  useful  guidelines  In  keeping 
the  breakdown  consistent. 

We  use  a  table  to  capture  this  Information,  but  there  are  also  graphical  and  al¬ 
gebraic  formats.  Computing  the  metrics  from  this  table  is  automatic.  We  have  a 
simple  application  which  can  do  it,  but  simple  arithmetic  is  all  that  is  involved. 

Doing  such  a  breakdown  is  easy  because  it’s  Intuitive.  Typical  processes  concern 
only  a  dozen  or  so  acts.  It’s  complicated  a  little  because  the  breakdown  introduces 
some  context,  this  from  the  original  agility  threat.  But  what  makes  it  possibly  ex¬ 
pensive  is  that  the  interesting  processes  we  are  monitoring  involve  actors  distrib¬ 
uted  among  suppliers.  Understanding  processes  in  suppliers  at  this  level  may  be 
difficult. 

This  sketch  simply  outlines  what’s  needed;  more  information,  of  course,  can  be 
provided. 


37.2.3.5  Actual  Questions 


For  each  process  that  you  identified,  please  tell  us  on  a  scale  of  1  to  5  how  dif¬ 
ficult  (meaning  costly)  it  will  be  to  get  the  information  we  noted.  Five  is  very  costly. 
Remember  that  you  need  to  include  suppliers  in  virtually  all  of  these  processes. 
(Please  give  us  a  rough  order  of  magnitude  how  many  dollars  per  process  you  have 
in  mind  for  the  1  through  5  assignations.) 

Please  let  us  know  for  each  process  whether  the  chief  cost  Is  in: 

^Sufficiently  educating  ail  parties  involved 
^Understanding  the  agents  (actors) 
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^Understanding  what  the  agents  do. 

37.2.4  Extra  Questions 

The  process  of  engineering  agility  follows  the  same  steps  of  engineering  other 
enterprise  attributes,  such  as  lean  or  quality.  In  all  cases,  the  steps  include  explic¬ 
itly  representing  your  processes  in  some  way.  It’s  widely  recognized  that  great  val¬ 
ue  come  from  that  step  alone,  even  discounting  further  steps  in  the  formula.  Just 
exposing  the  workings  of  the  enterprise  to  managers  in  a  comprehensible  way  has 
significant  power. 

Quite  apart  from  the  whole  process  of  engineering  agility  into  your  enterprise, 
do  you  think  this  perspective  provides  new  insights  into  your  processes?  Would  it 
make  sense  to  you  to  deliberately  use  this  type  of  system-level  view  of  coupling 
(across  the  larger  customer/supplier  chain)  to  offset  a  reporting  bias  of  other  ana- 
Ijlrical  views  that  might  slight  the  dynamic  coupling  of  processes? 

37.3  Questions  (No  Explanation) 

[The  same  questions  in  a  terse  format. | 

Please  review  the  example  cells  of  the  model  (or  cells  which  you  select)  and  let 
us  know  which  of  these  could  anchor  a  workable  agility  strategy,  given  the  scope 
of  the  agility  problem. 

^Please  note  these  few  cells  and  the  candidate  processes  that  might  support 
them. 

^If  it  is  interesting,  tell  us  why  the  others  aren’t  viable. 

For  each  process  that  you  identified,  please  tell  us  on  a  scale  of  1  to  5  how  dif¬ 
ficult  (meaning  costly)  it  will  be  to  get  the  information  we  noted. 

ilf  it  is  interesting,  give  us  an  indication  of  the  major  difficulties  which  make  it 
expensive. 

^Quite  apart  from  the  whole  process  of  engineering  agility  Into  your  enterprise, 
do  you  think  this  perspeaive  can  provide  new  insights  into  your  processes? 
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38  Case  Study  Results 

(The  results:  expectations  of  effectiveness  were  supported,  modeling  costs  are  about  SIM.  The  reasons  are  giv¬ 
en.] 

The  following  was  learned: 

^Although  the  benefits  of  agility  and  effectiveness  of  metrics  are  assumed  to  be 
reasonably  well  known  at  this  point,  devising  an  agility  strategy  is  non-trivial: 
^Agility  usually  costs  money  which  could  be  put  to  other  strategic 
investments;  relationships  of  agility  to  other  tactics  needs  to  be  evaluated. 
^Agility  in  some  dimensions  counters  agility  in  others,  so  the  general 
shape  and  likelihood  of  the  threat  needs  to  be  identified. 

^An  agility  strategy  needs  to  work  in  conjunction  with  other  elements  of 
strategies  within  the  virtual  enterprise  (market  dominance  versus 
immediate  profitability,  for  instance.) 

^An  agility  strategy  needs  to  leverage  natural  strengths  in  the  current  and 
possible  partners’  collective  and  individual  core  competencies  and 
management  philosophies. 

iThere  are  few  rules  of  thumb.  General  motivational  frameworks  by 
others  working  in  agility  are  not  very  useful  in  detailing  a  strategy.  It  is 
difficult  to  separate  different  pure  agility  from  more  general,  weaker 
definitions. 

^Evaluating  cells  of  the  Reference  Model  is  costly,  but  that  cost  is  in  line  with 
other  (equally  costly)  strategic  evaluations: 

^Parties  to  be  interviewed  will  be  unfamiliar  with  the  goals  and  purposes 
of  the  effort;  processes  to  be  surveyed  will  focus  on  traits  that  seem 
unfamiliar. 

4\t  will  be  easier,  faster  and  cheaper  to  model  the  process  elements  of 
interest  from  scratch  than  to  try  to  convert  from  existing  models.  In  part, 
this  is  because  the  details  of  verifying  correctness  and  completeness  in  the 
source  model  are  difficult;  the  mechanics  of  translating  among  model 
formats,  styles  and  methods  are  inadequate.  In  any  case,  the  information 
desired  will  not  exist  either  in  computable  models  or  in  a  readily  available 
recorded  form;  the  modeling  process  will  involve  the  cost  of  raw 
information  collection  in  essentially  all  cases. 

^Though  one  can  narrow  the  reference  model  down  to  a  few  key  cells, 
responsible  strategic  planning  demands  that  many  options  per  cell  be 
examined. 

The  actual  costs  for  our  of  modeling  for  our  scenario  are  between  $500,000  and  $1  Mil- 
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lion,  with  an  hourly  breakdown  per  cell  as  shown. 


1.3  Targeted  Market 

2.3  Partner  Search 
3.6  Risk/Reward  Strategies 

4.1  Performance  Metrics 
5.1  Identify  Need  for  Change 


Figure  38*1:Hourly  Costs  per  Target  Cell 

^These  costs  are  typical  for  similar  strategic  modeling  tasks. 

^We  uncovered  no  hidden  barriers,  no  deal  killers  in  the  basic  approach. 
^However,  it  is  clear  that  this  method,  or  any  other  strategic  agility 
planning  approach  is  in  need  of  production-quality  tools. 

^In  the  military  case,  these  should  be  integrated  with  the  weapons 
planning  and  evaluation  process  known  as  COEA  (Co5f  and  Operational 
Effectiveness  Analysis).  Probably  Virtual  Manufacturing  simulations  will 
be  involved. 

38.1  Discussion 

[The  costs  are  in  line  with  similar  strategic  modeling.) 

It  was  a  surprise  that  the  modeling  costs  what  it  does.  In  retrospect  we  feel  this 
is  because  the  community  has  an  idea  of  quality  metrics  which  can  be  applied  at  a 
fine  level  of  granularity  without  regard  to  strategic  issues.  Having  a  high  level  of 
quality  is  the  strategic  goal  that  is  served.  Agility  metrics  require  a  strategic  vision 
^and  vice  versa. 

Lacking  knowledge  on  modeling  costs  of  similar  strategic  tasks,  we  turned  to  a 
major  consulting  firm  (of  several  thousand  employees).  That  firm  performs  many 
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strategic  modeling  tasks,  discoveries  they  call  them.  The  typical  strategic  discovery 
is  $1  million,  apart  from  analysis  and  the  actual  planning. 

Clearly,  there  is  a  business  case  that  can  be  made  for  an  enterprise  to  do  such 
an  analysis.  No  small  firm  would  do  this  on  its  own.  It  would  have  to  be  done  from 
the  point  of  view  of  the  entire  AVE.  In  the  defense  case  (our  scenario)  agility  ben¬ 
efits  go  to  the  DoD  customer,  so  it  is  an  apt  function  for  them  to  sponsor. 
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39  Case  Study  and  the  ARRl  Method 

|How  the  metrics  could  be  folded  into  the  ARRI  tools,  as  representative  of  general  consultant's  tools.) 

The  ARRI's  enterprise  engineering  methodology  team  was  a  good  match  for  us: 

^We  were  both  sponsored  to  work  on  agility  and  there  is  a  specific  clause  in  all 
agility  contracts  that  encourages  (actually  requires)  collaboration  among  agility 
projects 

^They  work  in  the  aerospace  domain,  a  key  target  for  our  sponsors.  In  fact,  the 
Dallas/Fort  Worth  area  has  an  unusual  concentration  of  large  and  small  aero- 
space-related  manufacturers,  many  of  which  work  with  the  ARRl. 

^The  group  with  which  we  allied  has  an  enterprise  engineering  methodology 
which  represents  both  the  cutting  edge  of  research  and  the  moderating  infiuence 
of  practicality. 

iWith  us,  they  share  a  respect  for  social  and  cultural  issues  in  the  enterprise. 
^The  ARRl  hosted  an  NSF  workshop  on  agility  benchmarking  early  in  the  collec¬ 
tive  contracting  cycle  which  raised  many  important  issues. 

^They  have  been  active  in  the  AVE  Focus  Croup  hosting  a  half-dozen  meetings;  in 
BAST,  hosting  that  important  workshop:  and  also  in  the  ISIS-S/FIS  workshop  held 
in  Alexandria  VA. 

^Even  by  DARPA/NSF  standards,  their  work  is  first  class,  with  an  emphasis  we 
share:  methodological  rigor. 

^Their  definition  of  agility  as  A3  agility,  is  the  same  that  we  use. 

^Their  location  in  the  center  of  the  country,  near  a  major  hub,  is  very  conve¬ 
nient. 

Moreover,  they  complement  our  mission.  We  Intend  to  create  tools  that  con¬ 
sultants  (and  other  enterprise  analysts)  will  use.  They  serve  not  only  as  a  collabo¬ 
rator  and  auditor,  but  also  as  potential  technology  transfer  partner,  for  their  own 
use  and  demonstrating  for  others. 

The  ARRl  method  Is  typical  of  what  many  consulting  firms  do,  except  that  they 
have  a  greater  emphasize  in  rigorously  understanding  and  refining  the  process. 
They  have  a  way  of  decomposing  the  elements  of  an  AVE,  or  even  an  ordinary  com¬ 
pany,  into  primary  elements  which  reveal  its  behavior,  then  provide  engineering 
principles,  via  templateSy  to  accomplish  formation  or  reformation  to  optimize  cer¬ 
tain  goals. 

Their  decomposing  of  the  enterprise  is  consonant  with  our  reference  model, 
though  much  more  well  developed  because  we  need  to  support  only  agility,  and 
they  support  manifold  objectives.  Their  emphasis  on  templates  as  an  engineering 
tool  goes  further  than  our  metrics  in  that  we  measure  only;  they  measure  and  sug¬ 
gest  action.  However,  their  decomposition  lacks  the  internal  dynamism  required 
for  A^  agility,  which  we  can  add. 

>  The  next  section  outlines  the  salient  features  of  their  approach  from  our  per¬ 
spective  (by  no  means  being  a  fair  genera/  description.)  The  following  section  de¬ 
scribes  how  our  metrics  can  fit  in  as  a  special  purpose  tool.  That  description  is 
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indicative  of  a  general  class  of  similar,  though  less  formally  defined  approaches  to 
strategic  modeling. 

39.1  ARRI's  View  Breakdown 

|How  their  view  breakdown  fits  with  our  infrastructure  one.| 

(The  following  information  was  adapted  from  ARRI  material.) 

ARRI  considers  the  activity  as  the  basic  unit,  using  the  same  notion  of  activity 
we  do.  Concerning  these  activities,  they  are  motivated  to  know: 

^What  are  the  activities  that  an  enterprise  performs; 

They  seek  to  identify  the  essential  processes  (collections  of  directed  activities)  of 
the  AVE. 

dHow  should  these  activities  be  performed; 

They  describe  how  the  virtual  enterprise  and  its  members  will  perform  these  pro¬ 
cesses. 

^How  should  the  enterprise,  the  constellation  of  activities,  be  constructed; 

They  include  a  methodology  for  the  rapid  reconfiguration  to  the  AVE. 

We  address  only  the  first  two  in  the  metrics  phase,  and  the  third  in  a  future  tool 
strategy. 

In  order  to  address  these  process-centered  goals,  they  first  break  things  down 
into  five  views: 

dActivity  View:  defines  the  functions  performed  by  the  enterprise  (what  is  done). 
dProcess  View:  defines  the  time  sequenced  set  of  processes  (how  it  is  done). 

d Organizational  View:  defines  how  the  enterprise  organizes  itself  and  the  set  of 
constraints  and  rules  governing  how  it  manages  itself. 

dBusiness  Rule  View:  defines  the  entities  managed  by  the  enterprise  and  the 
rules  governing  their  relationships  (this  view  is  equivalent  to  an  information 
view). 

dResource  View:  details  the  resources  and  capabilities  managed  by  the  enter¬ 
prise. 

The  perspective  is  activity-based,  coming  from  an  industrial  engineering  per¬ 
spective.  The  bias  is  that  you  use  all  the  views  to  understand  what  you  are  about, 
but  your  primary  engineering  focus,  how  you  optimize  what  you  do  is  focused  on 
changing  your  activities.  Naturally,  you  modify  your  business  rules,  organization 
and  such  when  you  explicitly  consider  them,  but  the  engineering  value  is  in  how 
the  activities  can  be  optimized. 

ARRI  has  detailed  breakdowns  of  each  of  these  views,  based  on  the  state  of  the 
art  as  enhanced  by  intensive  real-world  application.  Each  of  the  views  has  com¬ 
pletely  differing  mechanics,  and  differing  methods  of  modeling  and  analysis  apply. 

A  significant  contribution  to  the  state  of  business  engineering  is  the  result  of  these 
insights  |ARRI91a  (ARR191b|  [IMR95j  [PJWL93). 
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The  first  of  these  five  views  is  the  world  where  the  primary  changes  can  take 
place,  as  weVe  noted.  We'll  come  back  to  that  in  a  moment.  Consider  the  other 
four.  These  represent  different  views  of  the  fabric  of  the  enterprise;  the  actual 
physics  in  each  view  are  different.  This  is  the  notion  The  AVE  Focus  Group  used  in 
defining  infrastructures.  You'll  recall  our  infrastructures: 

4 Social/Cultural:  dealing  with  hardwired  psychological  laws,  community  (ethnic, 
regional,  national,  etc.)  cultures  and  corporate  cultures 
4 Legal/Explicit,  broken  into 

4Business  Processes;  the  explicit  rules  for  how  different  elements  in  the 
enterprise  interact.  Who  supervises  and/or  certifies  which  persons, 
activities  or  work  products. 

4  Legal/Regulatory:  the  codified  definition  consisting  of  the  mostly 
external  constraints  governing  key  issues  of  how  the  organization 
functions. 

4WorkFlow:  the  logical  sequence  of  what  needs  to  be  done  by  whom, 
using  what  resources  and  in  what  order 
4Physical,  broken  into 

4  Logistics/Warehousing:  the  physical  sequence  of  what  needs  to  move, 
when  by  whom  and  where  from  and  to. 

4Equipment:  the  non-consumable  physical  resources  used  to  conduct  the 
work. 

4Physics:  the  immutable  laws  of  physics 

Note  that  there  is  an  almost  perfect  mapping  between  our  infrastructures  and 
ARRl's  views.  This  is  no  accident,  since  they  were  created  with  the  same  intent,  to 
segregate  behaviors  which  differ. 

Our  Business  Process  infrastructure  is  the  same  as  ARRl's  Business  Rules  view\  the 
Legal/Regulatory  infrastructure  maps  nicely  to  their  Organizational  view;  and  their 
Resources  view  has  the  same  definition  as  what  we  call  the  Equipment  infrastruc¬ 
ture. 

In  other  areas,  there  is  no  equivalent  for  our  Physical  infrastructure  which  is  no 
problem.  It's  pretty  useless  from  a  normal  decisionmaker's  perspective  and  we  only 
include  it  for  completeness.  ARRl  handles  information  technology  the  same  way 
we  do,  as  something  that  permeates  all  views.  We've  created,  for  academic  reasons 
the  Information  infrastructure  which  deals  with  issues  of  representation  and 
modes  of  communication,  but  that's  not  of  interest  in  engineering  at  the  enter¬ 
prise  level  which  is  why  ARRl  omits  it.  (It's  an  issue  for  government  investment  in 
next  generation  manufacturing  research,  which  is  why  we  include  it.) 

ARRl  is  more  consistent  than  we  are  concerning  social  and  cultural  issues.  Both 
of  us  believe  it  a  paramount  concern:  ARRl  deals  with  this  by  making  a  key  issue  in 
all  views,  as  they  do  with  information  technolo^.  We  denote  its  importance  by 
designating  a  separate  infrastructure  which  we  justify  by  positing  that  when  a  for¬ 
mal  physics  of  this  domain  is  found,  it  will  be  different  in  nature  than  the  relatively 
hard  behavior  of  the  other  infrastructures. 
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For  now,  it's  a  moot  point  which  will  be  settled  by  the  BAST  activity.  ARRI  has 
major  assets  engaged  in  BAST,  so  we'll  just  have  to  see  whose  expectations  were 
right. 

39.2  Process  View  Mismatches 

|The  one  apparent  mismatch  isn't.| 

There's  a  mismatch  of  sorts  with  ARRl's  Process  view.  WeVe  broken  that  one 
view  into  two  infrastructures,  the  Workflow  infrastructure  and  the  one  for  Logistics 
and  Warehousing.  We  separate  these  two  because  the  laws  at  work  are  different. 
The  laws  which  govern  material  movement  are  exclusively  physical;  The  Workflow 
adds  non-physical  criteria.  Elsewhere  we  note  that  Workflow  subsumes  Logistics 
and  Warehousing  and  that  an  adequate  description  of  the  former  covers  all  the 
needs  of  the  latter. 

So  why  do  we  maintain  the  separation?  Well,  many  of  our  infrastructures  are 
subsumed  by  others  in  this  fashion.  And  we  maintain  them  ail  because  different  de¬ 
cision  criteria  can  come  into  play.  Physical  constraints  are  so  much  more  easily 
dealt  with  that  we  want  to  limit  behavior  to  it  whenever  we  can. 

For  instance,  in  scanning  for  partners,  one  might  be  able  to  eliminate  or  other¬ 
wise  rank  those  which  for  physical  reasons  are  handicapped.  For  instance,  you  are 
likely  to  eliminate  a  refinery  from  your  petrochemical  workflow  if  it  is  on  the 
wrong  side  of  the  world,  regardless  of  incremental  novelty  on  process  technology. 

National  boundaries  are  still  defined  physically.  In  the  defense  world,  this  issue 
of  physical  location  matters  for  certain  key  components  as  well  as  a  critical  mass 
of  the  system. 

Let's  look  more  closely  at  ARRl's  process  view: 

4Generate,  Accept,  and  Fill  Order  for  Product:  Activities  related  to  marketing  the 
product,  order  entry,  production  planning,  manufacturing,  and  invoicing  custom¬ 
ers  for  products. 

4Generate,  Accept,  and  Fill  Order  for  Service:  Activities  Including  order  entry, 
whatever  service  function  was  required,  and  invoicing  the  customer  for  the  ser¬ 
vice. 

4Develop  a  New  Product  or  Service:  Activities  related  to  idea  generation,  market 
evaluation,  major  design  development  and  manufacturing  capability  evaluation. 
41dentify  and  Fill  Need  for  Non-Human  Resources:  Depreciable:  Activities  which 
identify  the  need  for  such  resources  and  acquire  and  manage  the  necessary 
resources. 

41dentify  and  Fill  Need  for  Non-Human  Resources:  Non-Depreclable:  Activities 
which  Identify  the  need  for  such  resources  and  acquire  and  manage  the  neces¬ 
sary  resources. 

►  4Identify  and  Fill  Need  for  Human  Resources:  Activities  which  identify  and  fill  the 
need  for  human  resources.  Includes  hiring,  compensation,  and  training  functions. 
4Appraise,  Improve,  and  Maintain  Human  Resources:  Includes  goal  setting,  data 
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compilation,  data  review  and  feedback  to  the  employee.  Also  development  of 
and  transfer  of  information  regarding  salary,  training,  or  other  motivational  pro¬ 
grams. 

4Appraise,  Improve,  and  Maintain  Non-Human  Resources:  Includes  data  collec¬ 
tion  a  the  operational  level,  data  review  and  evaluation  at  tactical  levels,  and 
development  of  and  transfer  of  information  regarding  resource  maintenance. 
4Develop  and  Translate  Strategic  Plans  to  Tactical  Plans:  This  process  covers  the 
development  of  long-term  plans  and  the  translation  of  these  plans  to  mid-term 
departmental  goals,  plans,  and  policies. 

^Translate  Tactical  Plans  to  Operational  Plans:  This  process  covers  the  transla¬ 
tion  of  mid-term  plans  and  policies  to  short-term  operational  procedures. 

These  processes  naturally  fall  into  three  categories: 

^Those  processes  which  use  resources  to  produce  enterprise  results  (The  first 
three). 

^Those  processes  which  acquire  and  prepare  resources  (the  next  five). 

^Those  processes  which  transform  external  constraints  into  internal  constraints 
(the  final  two). 

This  first  category  (the  first  three  processes)  include  our  logistics  and  warehous¬ 
ing  constraints.  There's  much  more  to  this  breakdown,  not  discussed  here  includ¬ 
ing  the  development  of  process  templates.  Since  ARRI  has  done  such  a  careful  job, 
it's  quite  easy  to  make  the  mappings  from  our  two  infrastructures  into  this  one 
view. 

In  short,  our  infrastructures  are  the  same  as  ARRl's  views. 

39.3  Activity  Model 

|How  ARRl's  aaivity  definition  compares  to  ours:  well  enough  to  believe  translation  tools  can  be  forthcoming. 
How  our  scopes  compare;  as  well  as  the  different  missions  would  allow.  But  there  could  be  a  problem.) 

The  ARRI  follows  a  breakdown  of  Enterprise  =>  Processes  =>  Activities  to 
reach  their  atomic  level.  We  follow  a  breakdown  of  Enterprise  =  >  Processes  =  > 
Process  Instance  (Cell  of  the  Reference  Model)  =  >  Communicative  Act.  Our  notion 
of  process  is  the  same  as  theirs,  but  we  cover  a  much  grander  scope,  focused  on 
the  whole  life  of  an  AVE. 

We  deal  with  issues  of  whether  the  AVE  should  exist,  should  make  something, 
what  it  might  be,  who  might  they  make  it  with  and  how.  ARRI  deals  only  with  the 
latter.  We  then  go  on  to  concern  ourselves  with  de-  or  re-composing  the  enter¬ 
prise. 

On  the  other  hand,  we  deal  only  with  agility,  which  although  new,  novel  and  im¬ 
portant,  is  only  one  of  the  many  issues  with  which  an  enterprise  would  concern 
itself.  The  two  approaches  are  complementary  in  this  regard,  which  after  ail  is  the 
Reason  for  the  collaboration. 

Back  to  the  decomposition  of  Processes.  The  differences  between  us  are  purely 
a  matter  of  the  modeling  methods  we've  chosen.  ARRI  is  using  the  venerable  IDEFO 
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methodology,  and  at  the  process  level  using  1DEF3,  a  widely  accepted  choice. 

u  special  purpose  representation  based  on  Dooley  Graphs. 

We  had  to  i  nvent  our  own  because  no  other  would  reveal  the  structure  of  the  pro¬ 
cess  which  is  indicative  of  adaptability. 

We  know  we  can  map  from  their  processes  to  ours  and  back.  It's  not  clear  that 
^"jP^p  from  representations.  We  spent  some  time  with  KBSl  who  are  refining 
an  IDEF6.  pere  is  planned  a  more  robust  way  of  coordinating  among  IDEFs  0, 3 
and  6  which  together  are  expected  to  be  able  to  support  Dooley  Graphs.  But  that's 
work  left  to  be  done. 

Simply  put,  there  is  a  workable  mapping  to  and  from  our  processes  and  ARRI's, 
with  the  promise  of  a  more  intimate  representational  mapping  forthcoming. 

Finally,  there  is  a  mismatch  between  the  overall  series  of  tasks  that  the  ARRI  ad- 
“resses.  The  overall  Enterprise  Transformation  Methodology  has  the  following  four 

^Develop  Vision  and  Strategy 
^Change  Culture 

^Integrate  and  Improve  Enterprise 
^Develop  Technology  Solutions 

There  rnay  be  an  important  philosophical  difference  here.  In  this  sequence 
(which  isn't  strictly  sequential),  we  can  help  with  only  the  third  step.  ARRI  follows 
the  widespread  convention  that  the  enterprise  should  be  tailored  to  meet  the  op¬ 
portunity,  that  the  opportunity  is  external  in  an  important  way  from  the  compe¬ 
tencies,  culture  and  resources  of  the  enterprise. 

The  AVE  Focus  Group  took  a  decidedly  different  view,  that  agility  depended  on 
an  introspective  vision  to  understand  what  competencies,  culture  and  resources 
might  result  from  a  manifold  partnership  and  to  extract  on  opportunity,  perhaps 
even  a  completely  unintuitive,  nonapparent  one. 

It's  hard  to  say  whether  this  philosophical  mismatch  would  act  as  a  barrier  to 
merging  the  two  approaches.  We  did  not  have  a  chance  in  the  case  study  to  test 
the  issue,  but  expect  to  have  an  opportunity  in  the  near  future. 
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40  A  Tool  Strategy 

JWhat  sorts  of  tools  are  expected  to  support  the  metrics.] 

This  section  provides  an  executive  overview  of  what  types  of  tools  are  envi¬ 
sioned  as  a  next  step.  One  of  these  tools,  Pomegranate,  has  been  prototyped  to 
the  point  that  it  can  be  useful  now.  Another,  Turnip  is  just  a  demonstration  of  con¬ 
cept. 

Four  applications  are  reviewed.  They  work  together  to  form  the  basis  for  a  gen¬ 
eral  framework,  based  on  a  deeply-ordered  conceptual  architecture  that  can  tie  to¬ 
gether  modeling  and  planning  tools  from  others  with  emerging  industry  standard 
collaborative  frameworks.  The  relationships  to  standards  and  frameworks  is  not 
discussed  here,  just  the  intrinsic  features  of  the  applications. 
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Figure  40-1  :Novel  Approaches  at  Each  Stage 


40.1  Brief  Overview  of  Applications 

(Outlines  four  tools  which  have  been  proposed.) 
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There  are  four  applications  all  together.  They  work  together  as  show  in  the  fie- 
ure.  We  use  their  temporary  code  names.  * 


Individual  Processes 


System-Level  Processes 


Figure  40-2:Tools  Inter-relate  with  Each  Other  and  Tools  by  Others 

by  3  decisionmaker  or  an  associ- 
concerned  with  process  models  at  the  individual  level.  Under- 
analjTical  capabilities  not  found  in  current  tools  is 
f  Po'^.^granate.  Among  these  properties  is  the  ability  to  evaluate  that 
process  s  dynamic  coupling  with  others,  which,  when  given  a  context  reveals  its 

r?  ?  ITff""  be  evalLted  for  othfr  charac^^^^^^^ 

^cs  as  well  (for  instance,  a  new  quantitative  basis  for  quality  that  is  not  emDirical) 

This  tool  would  be  best  used  In  conjunction  with  a  fulNfeatured  convenS^^^^^^^ 
eling  workbench  as  a  plug-in.  cnuundi  moo 

Mashed  Potatoes  is  its  counterpart,  evaluating  all  the  processes  in  a  Virtual  En- 

frnm  !r  agility,  or  some  other  system-level  metric  which  results 

from  binding  of  infrastructure  components.  Mashed  Potatoes’  primary  view  is 

TpTug'^i^  of  add^^i?^  intended  to  interface  with  business  planning  tools  (also  as 

iv  are  intended  to  supplement  decision-oriented  analyses  current- 

Ini^!  Tb^are  intended  to  integrate  with  current  and  planned  tool 

suites  m  those  domains.  Since  those  suites  are  so  radically  varled-as  well  as  the 
business  models  that  they  support-a  high  degree  of  flexibility  is  required. 

KA  ^ools  are  made  possible  by  the  underlying  framework  which 

Mashed  Potatoes  and  Pomegranate  employ  for  Internal  representation.  Xt  inter¬ 
nal  reprwentation  is  novel.  It  is  designed  to  be  scalable  to  complex  situations  to 

Th?!  of  individual  processes,  and  to  allow  model  federation. 

This  last  capability  allows  diverse  models  to  provide  Input  without  first  being 
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For  example,  if  you  were  a  manager  in  a  prime  and  wanted  to  evaluate  a  subcon¬ 
tractor  today,  you’d  need  their  processes  modeled  according  to  your  methodology 
and  standards.  Either  you’d  have  go  into  that  company  and  model  their  processes 
yourself,  or  you’d  somehow  force  them  to  do  it  for  you.  Much  of  prequalification 
of  suppliers  is  this  harmonization  of  process  methods.  This  is  harmful  to  the  en¬ 
terprise  because  it  typically  spends  more  money  on  method  harmonization  to  al¬ 
low  evaluation  than  on  novel  ways  to  integrate  and  leverage  processes. 

A  common  result  is  that  businesses  are  forced  to  change  their  business  philos¬ 
ophy  to  harmonize  with  the  prime’s;  it  makes  the  methodology  normalization 
much  easier.  The  bottom  line  is  that:  you  end  up  with  companies  that  operate  like 
yours,  even  though  competitive  advantage  often  comes  from  companies  which  dif¬ 
fer  completely  from  you  (which  is  often  the  primary  reason  for  teaming),  your  po¬ 
tential  partner  pool  is  limited  to  firms  which  self-select  to  go  to  the  trouble  to  do 
business  with  you. 

We  see  this  in  the  defense  subcontractor  base,  as  there  has  been  a  mass  exodus, 
and  since  you  need  to  use  a  general-purpose  methodology,  you  are  forcing  your 
suppliers  to  abandon  those  quirky  special-purpose  methods  that  may  have  been 
adopted  for  their  peculiar  niche.  The  result  is  that  all  of  the  really  capable  people 
in  your  enterprise  are  using  tools  that  are  less  powerful  than  they  would  otherwise 
choose. 


Model  federation  allows  the  subcontractor  to  use  whatever  modeling  method¬ 
ologies  they  have  chosen.  You  can  incorporate  that  into  your  system  model,  having 
it  appear  in  your  system-level  tools  as  if  it  were  modeled  in  your  lowest-common 
denominator  method.  You  can  engineer  your  whole  system,  perhaps  changing  the 
suppliers  process  (or  suggesting  changes).  Those  suggestions  are  seen  by  the  sub 
in  its  native  format.  Their  format  is  thus  federated  into  the  system. 

How  we  accomplish  model  federation  is  not  covered  here  [GORA92e).  The  col¬ 
lection  of  methods  we  employ  allows  for  tool  integration  as  well  and  empowers 
some  new  abilities  that  managers  may  wish  to  use.  Turnip  is  an  example  of  one  of 
these  new  tools.  Mashed  Potatoes  would  be  used  by  a  manager  whose  options  are 
constrained  by  business  options  and  guided  by  a  specific  business  strate^.  And  its 
representations  could  be  shared  with  tools  that  brainstorm  new  strategies  or  pro¬ 
cesses,  or  other  types  of  tools  that  evaluate  new  configurations  by  novel  simula¬ 
tions. 


Turnip  follows  a  different  strategy.  You  might  want  to  take  everything  that  you 
know,  information  about  all  your  possible  suppliers,  customers,  competitors,  and 
core  competencies  (which  have  been  federated  into  the  system)  and  noodle 
around  with  it,  looking  for  insights  hidden  in  the  mush.  This  is  much  like  what 
business  analysts  do  with  financial  models.  The  difference  is  that  what  we  have  are 
essentially  concepts.  Internal  to  Mashed  Potatoes,  we  turn  those  concepts,  fea¬ 
tures  within  them,  into  numbers,  so  that  the  financial  types  can  number-noodle. 

But  much  of  the  real  value  of  the  concept  is  lost  when  transformed  into  num¬ 
bers.  How  many  horror  stories  have  we  all  heard  about  bean  counters  making  de¬ 
cisions  based  on  numbers  that  are  clearly  wrong,  even  nonsensical?  Turnip  is  one 
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of  a  class  of  applications  that  provides  for  conceptual  noodling.  In  this  case,  the 

®  features,  since  that’s  clearly  a  high  payoff 
area.  But  other  features  could  be  used  as  well.  ^  b  f  y 

A  common  application  for  Turnip  might  be  to  browse  a  large  case  base  or  exoe- 
whflft/av  fh  hidden  or  underlying  lessons  learned,  and  whether  and^n 

£ering^^^^  problem.  The  mechanism  we  use  is  conceptual 

Alice  is  the  tool  for  a  whole  new  class  of  enterprise  engineering  geeks  we’d  like 
to  see  come  into  being.  Turnip  is  for  management  analysts.  Alice  is  for  the  pro- 

create  tools  like  Turnip  and  who  maintain  the  internal  work¬ 
ings  of  the  federation  mechanism. 


40.2  Implementation  Philosophy 

[Certain  technical  choices  were  made,  and  we  explain  why.) 

As  we  mernion  below,  these  applications  are  intended  to  be  useful  in  them- 

^“^'.^hed.  But  we’d  like  other  people  to  adapt  them,  extend  them,  and 
integrate  them  in  various  ways.  So  we’ll  be  giving  away  and  licensing  code.  As  a 
result,  we  have  to  be  more  careful  about  how  we  put  these  together  than  someone 
producing  and  selling  tools  in  the  conventional  manner. 

One  guiding  principle  is  to  use  a  visual  metaphor  all  the  way  down.  Evervthine 
IS  based  on  graphic  relationships.  We  divide  the  space  into  three  layers  and  have 
a  graphic  paradigm  for  each  of  these.  Because  of  fundamental  differences  among 
the  layers,  the  graphic  paradigm  is  not  exactly  the  same  as  you  go  down,  but  some 
key  relationships  and  principles  do  convey. 


DOOLEY  GRAPHS 


PROGRAPH  CPX 


GRAPH  GRAMMAR 


Figure  40-3:Three  Layered  Graphic  Interface  Paradigms 


At  the  highest  layer,  we  use  Dooley  Graphs.  These  are  similar  to  state  diagrams 
which  are  used  to  convey  who  said  what  to  whom.  We  get  a  lot  of  leverage  from 
^these  graphs  as  a  token,  because  they  can  be  abstracted  from  process  interactions 
(which  allows  us  access  to  model  theory),  from  communications  (which  lets  us  le- 
verage  conventional  information  theory),  and  agents  actions  (which  provides  a  ba¬ 
sis  tor  directed  concepts  and  a  host  of  associated  useful  disciplines).  Dooley 


Fttruary  15,  1997 


337 


Part  4.  Tool  Strategy 

Graphs  do  not  capture  all,  or  even  most,  of  the  semantic  meaning  in  a  collection 
of  models.  They  do  capture  completely  the  syntactical  structure  of  what  is  going 
on. 

At  the  programming  language  level,  we’ve  chosen  to  use  Prograph  CPX 
(SCHM94|  (SC95J  (SHAF941,  as  opposed  to  a  more  common  language  like  C  or 
C+ + .  We  did  this  for  a  few  reasons.  It  is  an  Object  Oriented  language,  which  helps 
with  designing  components  that  are  modular  and  reusable  by  others  in  a  sensible 
way.  More  iniportantly,  it  is  the  first  thoroughly  mature  graphic  programming  en¬ 
vironment.  It’s  graphic  ail  the  way  down;  there’s  no  text  code  involved.  Graphic 
languages  are  much  easier  to  convey  to  others,  because  the  program  structure  and 
intent  is  so  much  clearer. 

Also,  of  primary  interest  is  that  CPX  uses  a  dataflow  paradigm.  We  are  dealing 
in  an  area  where  we’ve  had  to  make  basic  decisions  about  how  we  deal  with  time, 
events,  causality  and  sequence.  The  dataflow  paradigm  somewhat  neutralizes 
these  confusing  issues.  It  doesn’t  matter  what  happens  when,  only  what  the  pre- 
and  post-  conditions  are.  This  also  makes  the  code  cleaner,  easier  to  follow,  and 
incidentally  closer  to  the  communication/agent  state  paradigm  that  we  would  like 
to  leave  to  others  (such  as  the  Industrial  Technology  Institute)  to  leverage. 

Finally,  at  the  bottom  level,  we  have  the  concept  engine.  This  is  no  trivial  piece 
of  work.  A  functional  programming  approach  (as  opposed  to  procedural  or  object- 
oriented)  is  required,  meaning  at  root  a  LISP.  However,  all  of  our  work  has  been  in 
instancing  concepts  in  a  graph  (or  lattice)  grammar.  In  effect,  this  is  also  a  graphic 
way  of  programming,  or  manipulating  concepts.  If  someone  wanted  to  tinker 
around  at  the  concept  level  (and  we  trust  there  are  those  who  do),  this  is  the  di- 
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mension  in  which  they  would  work.  An  example  of  a  typical  graph  from  similar 
work  in  Germany  (KAHL95]. 
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Figure  40-4:Kahrs  Graphs  of  Term  Grammars 


We  intend  to  leverage  leitmotifs,  conventions,  styles,  and  a  few  operators 
across  all  three  levels. 

Pomegranate's  class  structure  is  given  below,  as  Is  the  Dooley  Graph  algorithm 
Turn?p^^°  Also,  we  have  a  more  detailed  discussion  on  the  concepts  of 


40.3  A  Note  About  Names 

[Why  the  codenames  were  chosen.) 

You  may  be  wondering  why  we  chose  the  codenames  we  did.  They  are  all  silly 
But  m  the  spirit  of  full  openness,  here’s  the  scoop. 

Alice  is  the  Abstract  Lattice  Inte^ated  Conceptual  Environment  that  we  have 
been  working  on  for  some  time.  Historically,  a  test  for  such  environments  was 
whether  concepts  from  literature  could  be  captured  and  related.  The  book  we  test¬ 
ed  was  Alice  in  Wonderland.  (We’ll  publish  those  results  eventually.) 

One  would  work  with  Turnip,  the  concept  browsing  tool  to  see  what  would  turn 

^up. 

Alice  and  Turnip  are  underground  apps;  they  work  beneath  the  surface  of  con¬ 
ventional  business  operations.  Mashed  Potatoes  serves  up  some  of  those  under- 
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ground  products  in  a  satisfying  way  for  ordinary  people.  In  fact,  Mashed  Potatoes 
was  inspired  by  comments  made  at  the  Agility  conference  in  March  96  by  a  GM 
manager.  He  wanted  no  complications,  just  a  bubba  list  of  the  top  ten  things  he 
needed  to  do  to  be  agile. 

Fair  enough.  But  agility  has  a  lot  of  it  depends  qualifiers.  Mashed  Potatoes  allows 
a  normal  financial/management  bubba  to  scope  the  it  depends  factors,  and  see 
what  the  top  however-many  processes  are,  why,  and  how  much  they  contribute  to 
agility.  The  presentation  is  in  familiar  spreadsheet  format. 

Pomegranate  is  a  wholly  above-ground  fruit.  In  this  case,  we  decompose  the 
fruit  and  examine  each  of  the  cells  (that  is,  processes). 

40.4  Pomegranate 

[An  application  which  has  been  prototyped.  It  calculates  a  Dooley  Graph.] 

This  application  likely  would  be  the  first  one  of  the  four  encountered.  We  imag¬ 
ine  it  would  be  a  plug-in  or  an  internal  service  to  a  generic  modeling  workbench. 
A  model  has  to  be  entered  into  the  system  somehow;  perhaps  it  is  entered  by  the 
host  workbench,  or  federated  in  via  Alice.  Pomegranate  helps  the  process  deci¬ 
sionmaker  evaluate  some  features  of  the  model. 

The  features  of  these  models  which  are  of  interest  are  basic  properties  concern¬ 
ing  how  they  interact  with  each  other:  what  their  dynamic  combinatorial  proper¬ 
ties  are. 

Pomegranate  imports  the  process  as  is,  or  translates  it  into  a  communicative  act. 
This  format  is  tabular,  capturing  what  happens,  who  causes  it,  who  is  affected,  and 
implicitly  what  the  pre-  and  postconditions  are.  The  purpose  of  Pomegranate  is  to 
evaluate  a  given  process  or  to  explore  variations  on  those  processes  (and  even  new 
processes).  In  support  of  the  latter.  Pomegranate  has  a  speech  act  authoring  inter¬ 
face. 

One  could  tweak  the  models  in  either  this  form,  or  the  originating  form.  De¬ 
pending  on  how  the  model  is  connected  to  Pomegranate,  the  results  of  directed 
tweaking  would  be  reflected.  To  tweak  it  in  conversation  mode,  you  would  edit 
utterances  (components  of  the  conversation),  using  the  utterance  editor,  which  is 
opened  when  you  double-click  on  an  item  in  the  list,  or  edit  actors  directly  from 
the  conversation  editor. 

When  you’ve  got  something  you’d  like  to  evaluate,  the  Make  Dooley  button 
makes  the  Dooley  graph.  This  is  shown  in  the  Dooley  Editor,  a  mirror  ofwhich  will 
also  be  shown  in  a  blank  upper  right  area  of  the  Conversation  Editor. 

The  status  area  at  the  top  of  the  Dooley  window  has  information  about  the  met¬ 
rics  (the  five  basic  features  which  describe  dynamic  coupling).  By  highlighting  a 
node,  as  shown  in  the  window,  the  status  area  shows  information  about  the  select¬ 
ed  node.  Experimenting  with  new  designs  in  the  graphic  mode  will  also  be  sup¬ 
ported. 

The  strongest  part  of  Pomegranate  is  it’s  ability  to  suggest  changes  to  a  process 
by  reference  to  stored  (and  evaluated)  processes.  A  more  powerful  feature  is  a  li- 


Fcltruary  I5^  1997 


340 


Part  4.  Tool  Strate^ 


brary  of  promising  transforms  that  can  be  applied  to  a  base 
ways  of  achieving  desired  characteristics. 


process  to  explore 


Figure  40-5:Library  Connections 


Details  on  Pomegranate,  its  screens  and  implementation  structure,  is  below. 
40.5  Mashed  Potatoes 

|An  application  to  present  numbers  and  patterns  to  a  manager/analyst  in  spreadsheet-like  form.) 

Mashed  Potatoes  takes  information  on  processes  across  an  enterprise  and  eval¬ 
uates  Its  agihty  (or  other  dynamic  properties).  The  Virtual  Enterprise’s  agility  is  not 
^  of  agile  processes.  The  weighting,  dependencies  and  interc^nec- 
tions  are  complex,  but  there  needs  to  be  a  simple  way  to  play  what-ifs.  Mashed  Po¬ 
tatoes  provides  this  capability. 

Ordinarily,  one’s  first  Mashed  Potatoes  screen  would  be  the  Big  Picture  This  is 
a  familiar  spreadsheet  format.  What’s  represented  here  is  the  standard  model  of 
agility  processes  developed  over  a  period  of  a  year  and  a  half  by  the  Agile  Virtual 
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Enterprise  Focus  Group.  Down  the  side  are  the  processes  involved  in  the  lifecycle 
of  a  Virtual  Enterprise. 


1 

Toul  m  XX.XX 

BWAOI 

i^Dctuei 

CPiVfSCV.^ 

Arxuliooic 

WD£k  F3q* 

Ub^ltutx± 

timwm 

Opponuun  SimeirT 

X):  ytl 

>:x  XX 

XX  xy 

XX  XX 

xy  yy 

XX  XX 

xxxx 

XX  XX 

KX  XX 

XX  XX 

XX  YX 

XX  XX 

TitHfitod  Mirkpf 

xy  y>! 

yx  XX 

XX  xy 

XX  XX 

yy  yy 

XX  XX 

Swclr 

Xa.a>: 

>:x  XX 

XX.Xa 

XX  XX 

xy  .y  X 

XX  XX 

Pk.TtDrr  QuiL})f  KStioa 

X>i  'A  )« 

yx  XX 

XX.Xa 

XX  XX 

xy.yx 

XX  XX 

Pi(t»cr 

YX  YX 

XX  XX 

XX  x>: 

XX  XX 

YX,  XX 

XX  XX 

Pjnaer  ScaTidi 

X}:.y>: 

yx  XX 

XX  xy 

XX  XX 

xy  yy 

XX  XX 

VaiMb^RXiMT  De^^voMc 

X):  yj: 

yx  XX 

XX  xy 

XX  XX 

yy  yy 

XX  XX 

.Pictsm  Coima/Stftecbo'D 

XX.XX 

>:x  XX 

XX  XX 

KXXX 

xy.yx 

XX  XX 

SeitnanaeM^rnp. 

xy  y): 

>:xxx 

XX  xy 

XX  XX 

yy  yy 

XX  XX 

CipitaJiza^o 

X/i.XX 

yx  XX 

XX.XX 

XX  XX 

WKS3^ 

XX  XX 

F<«dMa  LahbM 

yy  yx 

XX  XX 

XX  XX 

XX  xr 

x>:  >:x 

XX  XX 

Rjfct/Rrw&Td  STTaitflt 

XX.XX 

yx  XX 

XX  X); 

XX  XX 

xy  yy 

XX  XX 

OwTVtOI  SlClfOtUtC 

XX  xx 

XX  XX 

KX  XX 

XX  XX 

x>:>:x 

XX  XX 

Diiuol\iboaPI]B 

xy  yy 

yx  XX 

XX  xy 

XX  XX 

yy  yy 

XX  XX 

?«iiorwQ^  Moiurpt 

xy  yy 

yx  XX 

XX  xy 

XX  XX 

yy  yy 

XX  XX 

CufckszM^  Rrhtwm 

XX  .X  X 

yx  XX 

XX.XX 

XX  XX 

xy./:x 

XX  XX 

OotatM  PcMMe 

yy  yy 

XX  XX 

XX  XX 

XX  XX 

XX  XX 

XX  XX 

N  ocd  JckptificaMa 

>:>:  XX 

XX  XX 

x>:  YX. 

XX  x>: 

>:>:  >:x 

XX  XX 

LiibDiDeb 

xy  yy 

yx  XX 

XX  XX 

XX  XX 

yy  yy 

XX  XX 

ALbcVCauitr  I^Tscni] 

XX  .X  A 

XX  XX 

XX  XX 

XX  KX 

xxxx 

XX  XX 

_  _  _  _ 

Figure  40-6:The  Big  Picture  Window 
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Across  the  top  are  two  large  categories  representing  the  two  major  infrastruc¬ 
tures:  Legal/Explicit  and  Physical,  with  each  of  them  broken  down  into  three  divi¬ 
sions  each.  Clicking  in  many  cells  opens  a  definition  or  explanation. 

Defioition  I 


OcprrfwutT  1  ]  Ojppoftuvir  7 

[q  &rdcriD  sd<Qbf7  iDonp^tnicatf.  the  w  liiweaiiTifKif.  Tit  ooru&tbc  c^vimtaod 

^ril  tfai^^odl  ir^m  tbc  onH  id  briiodm^  a«d  »40pir»i  hr  poXnt^  oaxAm^pi  ibc  AVB 

JUm  tbokJd  he  v  ^^pki  ic  ibe 

ivdcpcDdciLij;  eooduci  d»rowaaxul7^a.  Hie  lorwcacuot  ibe  Ve  uavmuniT  fqcuabe««d  Nb^lbio  te 

iWuJd  It  9  DC4Vk  fcr  6c  vf  ibc«ppo<tu»t7  p^lrabil  psctanv 

faeoLAe  /u:]  dkclaLure OQ*Jd  caieiv  eapowerii^  ai ocapeok^T  7^  luunpooa  s.  611  market  ietfocaiDoo  «pjI)  be 
dibtobmrclattoiu  Cinu,  a1  t«utmlbc  Ttpc  I  A  VS,  bo  6al  &  ooinlavad  m*iBl  bexTalbcaiMd  CcH&ir^en] 

Kctwiu  «  ibe  ibewf,  nrl?  iq  tbrcnM  rcecm  Ibrre  mMil  be  soowbtecl  uodmu^Bjc  of  ««bc  &  lbe'*]cQd‘'  Coc  6e 
AVB  (a:  IcAl  lor  6ib  pba^r)  Tbor  xdmj  bc\xvleTv  aod  ■‘sv^lv^d  »bv  ^rcbpcrolib^  ralbcb^mlrjrr  TV 

LtraKi^f  L VUd  be  hoiad  0%  s  airiS^v<  fee  de^iun^  acid  dckcnnicaa^  06Te  mnnifTTfcin  TVae  wi!]  prob»bi7 

be  M  ncapae  telaboubbip  bweec  cbanctnibbcfc  of  6e  oppoThicnr  (u  <iefiood  by  ib<  ilraiejiT)  and  CDie  cocBpnciKi& 
of  6c  ^it«Tw  Tbc  btwtrjfT  4lwu  oocrla  %  toceruorair  a  of  wKii  «'04.bh.Hsi  btMocbr  Tl%  ^afyuboa  of  biMcvv 
IP  i3  form  6e  boiit  iot  111307  yi^vyrm  which  h&JIcw  P^caJ)/.  the  i7ian^7  aiL±i  ba^  a  waj  of  dcKnaidc^ 
w  briber  6c  opprrtuiuTT  &  a  aicnui  cmdi^ie  for  beina  addmaod  br  cfmtbAc  AVfi  ( Al  6ib  poniv  6c  AVSenIma 
arc  prolwhlj  iic^oowq ) 


Figure  40-7:A  Typical  Definition  Window 


The  More  button  opens  the  HTML  version  of  the  evolving  Metrics  project  report. 
Clicking  in  the  Column  Headers  expands  that  column  into  five  subcolumns.  Effec¬ 
tively  the  spreadsheet  has  30  columns,  but  we  collapse  it  this  way  to  make  it  easier 
to  see  patterns.  The  complete  infrastructure  breakdown  is  in  Part  1 . 
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.U  ^  and  Technology  Institute’s  Situation  Theoiy  work  is  productized, 

the  Socia^CuItural  Infrastructure  will  be  added.  One  of  these  Column  Expansions 
IS  shown  below.  ^ 
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Figure  40-8:The  Column  Expansion  Window 
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Alternatively,  one  puld  click  on  a  cell  in  Big  Picture,  and  have  the  Cell  Expansion 
screen  opened.  This  is  simply  one  row  of  the  column  expansion,  but  it  contains  ad¬ 
ditional  descriptive  text  about  the  process. 


Figure  40-9:The  Cell  Expansion  Window 

All  of  these  screens  consist  of  numbers  which  give  a  composite  number  of  the 
agility  of  the  process  or  collection  of  processes  to  which  the  cell  refers;  the  upper 
left  of  Big  Picture  gives  the  agility  metric  for  the  whole  VE.  Each  of  these  presumes 
a  specific  context,  as  we’ve  described  elsewhere. 

The  cells  of  the  Column  or  Cell  Expansion  represent  small  individual  processes. 
Clicking  on  them  opens  the  Process  Selection  screen.  This  complex  screen  is  the 
core  of  the  application.  The  currently  selected  process  for  that  cell  is  shown:  a  text 
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description,  the  Dooley  Graph,  and  the  original  form  of  the  model  (the  cartoon 
here  indicates  in  IDEF3). 

Op<>»»<  I  A<i>rr  I  WcmbiiM  I 

A  I  I  y>:>:x  |  F(,i,.ili()n  t  ] 

t(|U.ilinii  »  I  1^  <»  I''"'  A 

r(|it.ilir)ii  v  | 

E(iijiiii()ii  *r> 


o  o  □  □ 

Dcioli'y  O^ph  Numbc'r  1  IDCF  \  [>ia>;r.»«  NiimlM>r  I 

o  ° 


Figure  40-10:The  Process  Selection  Window 


Also  shown  is  the  calculation  of  the  five  agility  features  (which  follows  directly 
from  the  Dooley  Graph)  and  the  approximate  combined,  single  number  for  the  pro¬ 
cess. 

Clicking  on  each  of  the  process  representations  (it’s  number,  name,  text,  Dooley 
or  1DEF3  representation)  opens  a  popup  of  stored  alternatives  of  processes  that 
could  satisfy  that  cell.  A  manager  could  select  an  alternative  process  to  see  how  its 
agility  evaluates  against  the  situation  (which  is  provided  by  other  tools,  such  as 
that  being  incubated  at  the  Automation  and  Robotics  Research  Institute).  Also,  the 
manager  can  see  how  the  selection  affects  the  agility  of  the  entire  supply  chain, 
both  by  seeing  the  weighting  number  and  seeing  how  the  combined  number 
changes  in  Big  Picture. 

Again,  we  describe  elsewhere  that  a  process  isn’t  intrinsically  agile  or  not,  it  only 
ibecomes  so  when  combined  with  others  in  an  agility  strategy.  Also,  it’s  importance 
depends  on  the  situation  in  which  the  agility  matters. 
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An  additional  capability  to  be  added  would  extract  the  key  processes  (there  will 
only  be  a  few)  and  present  them  in  a  ranked  list  so  that  everyone  in  the  supply 
chain  knows  what  the  key  processes  are  to  support  the  strategy  and  the  scope. 

Mashed  Potatoes  is  a  client.  It  gives  and  takes  processes  and  metrics  from  two 
sources:  processes  from  a  library  served  by  something  like  Pomegranate;  and  met¬ 
rics  to  and  from  an  organization’s  parametric  planning  software.  (As  one  common 
format,  Mashed  Potatoes  exchanges  with  Excel.)  In  this  way,  Mashed  Potatoes 
forms  a  bridge  between  logical  models  used  by  process  designers,  and  parametric 
models  used  by  planners  and  managers. 

40.6  Turnip 

(An  advanced  what  if  tool*  based  on  proprietary  indexing  science.) 

Mashed  Potatoes  is  a  bridge  between  models  and  numbers,  or  more  precisely 
between  logical  and  parametric  models.  As  described  above,  the  initial  use  of 
Mashed  Potatoes  will  be  to  feed  parametric-based  planning  tools.  The  better  of 
these  will  employ  sophisticated  methods  such  as  multivariate  analyses.  The  less 
sophisticated  will  simply  use  numerical  methods. 

But  in  both  cases,  the  analyses  will  be  on  numbers.  But  our  approach  allows 
something  more  capable.  On  the  way  from  a  logical  model,  based  on  set  theory,  to 
numbers,  we  employ  a  category-theoretic  abstraction  of  process  features.  It 
should  be  possible  to  perform  system-wide  operations  on  these  concept  features. 
Such  analyses  would  be  much  more  insightful  since  we  are  working  with  concepts 
directly  rather  than  numbers  which  are  a  mere  shadow  of  those  concepts. 
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Turnip  is  one  of  that  new  breed  of  analytical  tools.  How  it  fits  with  the  other 
tools  is  shown. 


Turnip 


Strategy 

Tools 

(ARRI) 


Alice 
(Concept 
Feature  Base) 


Pomegranate 


Strategic 

Planning 

Database 


Mashed 

Potatoes 


Control 

System 

(ITI) 


Figure  40-1 1  :Turnip  Supports  Feature  Analysis 


The  purpose  ofTurnip  is  to  load  concepts  from  all  the  process  options  (different 
processes,  different  suppliers),  all  the  strategic  options,  and  all  the  various  agility 
scenarios.  This  could  be  a  very  large  number  (millions  or  hundreds  of  millions). 

The  idea  behind  Turnip  is  to  form  concept  vectors,  which  is  easy  to  do,  almost 
automatic,  with  our  graph  representation.  As  with  all  our  tools,  we  inherit  tech¬ 
niques  developed  elsewhere.  In  this  case,  the  techniques  are  from  the  Computa¬ 
tional  Fluid  Dynamics  area,  with  the  cutting  edge  work  being  done  by  Sandia 
National  Lab. 

In  Turnip,  we  define  a  five  dimensional  concept  space,  each  dimension  repre¬ 
senting  one  of  the  features.  In  the  figure,  you  can  see  that  we  either  display  or  en¬ 
ter  information  into  two  dimensions  at  a  time.  The  horizontal  plane  is  the  x-y  plane 
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of  those  two  dimensions.  The  z  (vertical)  dimension  is  the  density  of  the  concepts 
in  the  space. 
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Figure  40*12:Two  Views  of  Two  Dimensional  Vector  Bundle  Density  in  the  Five 

Dimensional  Turnip 
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In  another  version,  we  work  in  ten  dimensions,  adding  dimensions  for  concept 
granularity.  (Any  number  of  new  feature  spaces  can  be  employed,  allowing  evalu¬ 
ation  of  characteristics  beyond  agility.) 
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Figure  40-1 3:Two  Views  of  the  Ten  Dimensional  Turnip 


What  the  analyst  is  looking  for  as  the  spaces  are  browsed  is  clustering  of  con¬ 
cepts:  needs  and  solutions  in  the  same  space  (strategy  being  either).  The  concepts 
in  Turnip  can  be  passively  displayed,  imported  from  a  concept  base  like  Alice 
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[GORA92il,  or  they  can  be  entered  directly  in  the  windows  shown,  by  drawing  a 
concept  flux  density  column. 

As  in  Mashed  Potatoes,  system  level  evaluations  of  agility  are  computed.  Each 
situation  is  considered  a  document  and  can  be  saved.  Situations  can  be  compared, 


Metric 
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dollar  cost  $776 
time  cost  8  days 


Figure  40-14:Any  Number  of  Enterprises  or  Possible  Enterprise  Configurations  can  be 

Compared 


Each  situation  is  evaluated  as  to,  in  this  version,  the  time  and  cost  of  accom¬ 
plishing  something,  in  this  case,  the  combined  cost  of  changing  processes  and  de¬ 
signing/manufacturing  with  the  new  supply  chain  and  new  processes.  Two 
situations  can  be  compared  from  a  scrolling  list  of  many  situations  and  the  time/ 
cost  differences  computed. 

Mashed  Potatoes  is  intended  for  existing  decisionmakers;  Turnip  is  designed  as 
a  tool  for  a  new  class  of  decisionmaker. 

40.7  Future  Work 

[The  intent  to  see  these  tools  in  widespread  use,  embedded  in  more  comprehensive  workbenches.) 

We  plan  to  take  the  components  from  the  products  and  divide  them  into  two 
classes.  One  class  will  comprise  useful  stuff  in  and  of  itself  that  we  will  make  free¬ 
ware,  or  essentially  so.  We’re  checking  into  copyleft^  an  open  sharing  system  orig¬ 
inated  by  the  Free  Software  Foundation. 

The  other  half  will  be  licensed.  In  both  cases,  we  plan  to  distribute  some  source 
code. 

^  Meanwhile,  you  can  download  current  versions  of  Turnip,  Mashed  Potatoes,  and 
Pomegranate  to  play  with.  This  is  all  pre-alpha  code,  developed  for  internal  learn- 
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ing  purposes.  A  patient  explorer  should  be  able  to  see  what  we’re  about.  Use  at 
your  own  risk!  The  web  site,  if  you  are  reading  a  paper  copy  of  this  document  is: 

<  http  :/Avww.agiIityforu  m  .org/Ex_Proj/M  AVE/mave  .html  > 

By  the  way,  these  only  run  on  Macs.  We’re  developing  on  Macs  since  only  they 
have  the  3D,  other  graphics,  and  the  possibility  of  dynamic  object  support  in  the 
kernel.  The  tools  themselves  will  be  multiplatform  of  course. 
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41  Pomegranate 

(This  is  the  design  report,  explaining  the  structure  of  the  prototype.) 

Information  in  this  section  was  provided  by  Tangent  Systems: 

John  Shackelford 

Director  Product  Development 

Tangent  Systems 

4546  Del  Mar  Avenue 

San  Diego,  CA92107 

Email:  shackx@aol.com 

Web:  http://www.tangentsys.com 

Fax:  619/222*1442 

41.1  Document  Scope 

(What  the  document  is;  a  report  on  an  emerging  prototype.) 

This  document  collects  the  requirements  for  the  Pomegranate  application,  gen¬ 
eral  goals  for  the  application  and  major  design/implementation  decisions  in  the  ap¬ 
plication.  This  document  is  not  strictly  a  requirements  document  -  it's  more  a  livins 
design  document  which  tries  to  capture  the  major  drivers  for  the  application.  The 
implementation  information  is  Included  to  give  some  context  for  discussing  what 
the  application  does.  * 


41.2  Purpose 

[The  prototype  captures  a  conversation  (process),  produces  a  Dooley  Graph,  and  prepares  to  report  the  metrics.) 

The  purpose  of  the  application  is  to  provide  a  means  to  capture  a  conversation 
^  defined  by  its  utterances  and  participants,  evaluate  the  conversation  using  the 
Dooley  Graph  algorithm  (described  in  the  next  section)  and  then  to  ultimately  pro¬ 
vide  a  mechanism  to  compare  Dooley  Graphs.  The  goal  Is  to  provide  a  framework 
to  measure  the  Agility  of  a  conversation.  The  application  will  initially  support  the 
use  of  Dooley  Graphs  as  the  mechanism  for  representing  a  conversation.  A  conver¬ 
sation  can  include  the  conversation  that  occurs  between  humans  or  organizations 
in  an  attempt  to  accomplish  a  goal.  The  Dooley  Graph  and  metrics  of  a  Dooley 
Graph  may  be  used  in  a  comparative  sense  to  assess  and  predict  the  Agility  of  the 


41.3  General  Application  Requirements: 

[A  list  of  the  first  stage  requirements.] 

^Provide  a  means  to  capture  the  utterances  in  a  conversation. 
^  ^Provide  a  means  to  define  the  type  of  utterance. 

^Provide  a  means  to  define  the  sender  of  an  utterance. 
^Provide  a  means  to  define  the  reclpient(s)  of  an  utterance. 
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^Provide  a  means  to  define  the  participants  involved  in  a  conversation. 
^Provide  a  means  to  calculate  the  Dooley  Graph  of  a  conversation. 

^Provide  a  means  to  display  the  Dooley  Graph  of  a  conversation. 

^Provide  a  means  to  import  conversation  models  from  external  source  files. 
^Provide  a  means  to  apply  various  metrics  to  a  Dooley  Graph. 

^Provide  a  means  to  compare  a  set  of  Dooley  Graphs. 

^Provide  a  means  to  print  Dooley  Graphs. 

^Provide  a  means  to  Copy  Dooley  Graphs  as  pictures. 

4 Provide  a  means  to  print  Conversation  information  in  tabular  form. 

^Provide  a  means  to  inspect  the  metrics  of  a  Dooley  Graph. 

^Provide  on-line  help. 

41.4  Pomegranate  Implementation 

[We  used  Prograph/CPX.J 

The  prototype  for  the  Pomegranate  application  is  being  built  using  Prograph/ 
CPX.  Prograph/CPX  is  a  cross-platform  visual  data-flow  object-oriented  program¬ 
ming  language  and  is  produced  by  Pictorius,  Inc.  of  Halifax,  Canada.  The  applica¬ 
tion  has  won  numerous  productivity  awards  within  the  industry.  The  development 
environment  includes  a  rich  application  framework,  integrated  application  editor, 
interpreter  and  editor.  CPX  currently  builds  applications  for  Macintosh,  Power 
Macintosh  and  Windows  operating  systems.  The  development  environment  sup¬ 
ports  the  development  of  applications  using  state  of  the  art  object-oriented  pro¬ 
gramming  concepts.  The  basic  application  features  rely  on  the  CPX  class 
framework  -  Application  Building  Classes. 

41.5  Pomegranate  Application 

pescribes  the  workflow  and  support  funaions  of  the  prototype.] 


41 .5.1  Work  Flow  Scenario 

[The  steps  a  user  would  go  through.| 

4  User  creates  a  new  or  opens  existing  Conversation  Document,  This  results  in  a 
Conversation  Document  being  created  along  with  a  Conversation  Object  and  a 
Conversation  Editor  begin  opened. 

4User  specifies  the  number  (x)  of  actors  involved  in  the  Conversation.  This 
results  in  x  Actor  objects  being  created  and  sent  to  the  Conversation  object. 

4 User  adds  utterances  (here  the  user  can  add  several  utterances  or  single  utter¬ 
ances  and  edit  each  individually  prior  to  adding  another).  The  editor  provides  a 
means  to  add  new  utterances  to  a  conversation. 

4  User  edits  Utterances.  The  Conversation  Editor  window  provides  a  list  of  utter¬ 
ances  contained  by  the  conversation.  The  editor  also  provides  a  means  for  the 
user  to  select  a  specific  utterance  to  be  edited.  The  result  is  the  Utterance  Editor 
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is  opened  with  the  specific  Utterance  being  the  customer  for  its  service. 

^User  asks  the  application  to  calculate  the  Dooley  Graph.  The  Conversation  Edi¬ 
tor  provides  a  means  for  the  user  to  start  the  Dooley  calculation  process. 

^The  application  creates  a  smart  graphic  in  that  the  information  driving  the 

Dooley  Graph  (the  nodes  and  arcs)  can  be  directly  Inspected  within  the  graphic 
object. 


41.5.2  Support  Functions 

[Miscellaneous  preferences.) 

Preferences:  The  preferences  in  Pomegranate  provide  the  capability  to  activate 
the  rnetrics,  enable  drag  and  drop  of  files  between  projects  and  enable  the  data¬ 
base  functions. 


Preferences 


1 


7iiiii  I 

Hiiii  I 


^  Distance  Metric 
S  Deiay  Metric 
0  ^  Mouability  Metric 
0  E  Importance  Metric 
|mj  E  Frequency  Metric 

^  Enable  File  Drag  &  Drop? 

□  Enable  Basic  Enterprise  Database  Tools? 


[  Cancel 


Figure  41-1  iPomegranate  Preferences  Window 


41.6  Pomegranate  Design 

[Describes  how  the  elements  of  the  prototype  appear  and  work.) 

41.6.1  General  Concepts 

[Describes  generally  the  inputs  (utterances)  and  the  output  (a  Dooley  Graph).) 
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The  mode/  for  the  design  is  derived  fromlPARU96aJ  (PARU96bl  IPARU96cl.  The 
paper  discusses  in  detail  an  approach  to  the  definition  of  utterances  and  how  the 
Dooley  algorithm  can  be  used  to  define  the  Dooley  Graph  for  a  conversation.  The 
general  idea  is  to  provide  a  set  of  editors  which  capture  the  basic  elements  of  a 
conversation.  Those  elements  include: 


iThe  set  of  participants.  (Actors) 

^The  set  of  utterances.  (Utterances) 

^The  relationships  between  sender  and  receivers)  of  each  utterance  (Utterance 
Editor) 

^Contain  these  elements  inside  of  a  conversation  object.  (Conversation) 

^Define  a  class  of  objects  which  work  with  the  Conversation  to  encapsulate  the 
idea  of  a  Dooley  Graph. 

Once  the  conversation  is  defined,  the  Dooley  Graph  is  calculated  using  the 
Dooley  algorithm  or  a  function  based  on  the  Dooley  algorithm.  The  graph  is  dis¬ 
played  in  a  window.  The  Dooley  Graph  window  will  also  display  a  set  of  metrics 
which  are  to  be  determined  -  but  will  give  a  measure  of  the  Pomegranate  of  the 

depicted  conversation.  These  metrics  will  then  provide  a  basis  to  compare  to  other 
conversations. 


The  use  of  the  application  centers  around  a  handful  of  editors.  Each  editor  is 
used  to  specify  detailed  information  of  a  certain  kind  to  help  define  a  conversation 
or  a  set  of  conversations: 

^Project  Window  -  Manages  a  set  of  Conversation  files. 

^Conversation  Editor- Add  and  delete  utterances  and  actors  in  a  conversation. 
^Utterance  Editor  -  Define  specifics  of  an  utterance, 

4Dooky  Graph  Window  -  View  the  Dooley  Graph  for  a  conversation. 


41.6.2  Project  Window 

|A  collection  of  conversations  (processes)  is  a  project  (enterprise).) 

The  project  window  manages  a  set  of  conversation  files  or  documents.  The  win¬ 
dow  is  designed  so  that  related  conversations  can  be  grouped  within  a  project  in 
order  to  compare  the  metrics  of  the  conversations.  The  window  provides  the  abil¬ 
ity  to  CTeate  new  conversation  files,  add  existing  conversation  files,  remove  con¬ 
versation  files,  duplicate  conversation  that  exist  in  project  and  to  edit  conversation 
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files  in  the  project.  The  Project  Window  also  provides  a  way  to  sort  the  conversa¬ 
tions  using  any  of  the  available  metrics. 

Add  New  Conversation 


Figure  41-2:Project  Manager  Window 


Summary: 

4Button  -  Add  New  Conversation 
^Button  -  Remove  Selected  Conversation 
4Button  -  Add  Existing  Conversation 

4Popup  Menu  -  Sort  Conversations  according  to  selected  metric. 

4Grid  -  Display  basic  information  about  each  Conversation  in  project.  Provide 
access  to  selected  Conversation  file  by  double  click  action  within  the  grid. 

41 .6.3  Conversation  Editor 

|A  Collection  of  utterances  (speech  acts)  is  a  conversation  (process).] 

The  Conversation  Editor  provides  the  means  to  add  and  delete  actors  and  utter¬ 
ances  in  a  conversation.  It  also  provides  the  function  to  calculate  the  Dooley  Graph 
for  a  conversation. 

Summaiy 

4Button  -  Add  New  Actor 
I  4Button  -  Remove  Selected  Actor 

4Select  List  -  Display  Actors  in  Conversation 
4Button  -  Add  New  Utterance 
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Remove  Selected  Actor 
\  Add  New  Actor 


Actors  List 


Add  New  Utterance 

Delete  Selected  Utterance 


Utterance  Summary  Grid 


Calculates  Dooley  Graph  and 
Opens  Dooley  Graph  Window  for 
Display 


Figure  41-3:Conversation  Editor 


^Button  -  Delete  Selected  Utterance 

4 Button  -  Calculate  Dooley  Graph  and  Display  Graph  in  a  window. 

4Grid  -  Display  summary  information  about  Utterances  and  provide  access  to 
edit  selected  utterance  by  double-click  action  in  the  grid. 

41 .6.4  Utterance  Editor 

(This  editor  specifies  details  of  utterances.) 

This  editor  allows  for  detailed  specification  of  utterance.  The  sender  of  utter¬ 
ance  can  be  specified  along  with  the  actors  that  receive  the  utterance.  The  utter¬ 
ance  type  is  also  specified.  The  window  also  provides  functions  to  select  other 
^utterances  in  the  conversation  for  editing. 

As  can  be  seen  in  the  figure,  the  Utterance  Editor  Window  provides  several  fiinc 
tions  for  specifying  the  nature  of  each  utterance: 
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Source  Conversation  and  Utterance  in  Editor 


Figure  41-4:Utterance  Editor  Window 


^The  sender  of  the  utterance  is  specified.  Once  this  selection  is  made,  the  sender 
actor  is  removed  from  the  selection  list  for  specifying  who  is  to  receive  the  utter¬ 
ance. 

^The  recipients  of  the  utterance  are  then  specified  by  double-clicking  selections 
in  the  left  hand  scrolling  list  in  the  window.  Each  selection  will  be  then  be  added 
to  the  recipients  list  on  the  right-hand  side  of  the  window. 

^The  type  of  the  utterance  is  then  selected  from  the  Type  pop-up  menu  item. 
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dThen  •  and  this  is  cmcial  for  proper  operation  or  calculation  of  the  Dooley 
Graph  -  are  the  selections  for  Reply  To,  Resolves  and  Completes.  Please  refer  to 
(PARU96a]  for  a  discussion  on  what  these  attributes  mean.  Simply  put,  each  of 
these  selection  defines  which  utterance  the  current  utterance  Completes, 
Resolves  or  is  a  Reply  To. 


41.6.5  Dooley  Graph  Window 

(The  Dooley  Graph  is  displayed  here.I 

This  window  can  only  be  opened  from  the  Conversation  Editor.  It  is  opened 
when  the  Do  Dooley  button  is  pushed  in  the  Conversation  Editor  and  displays  the 
Dooley  Graph  graphically.  The  window  also  provides  buttons  for  display  of  each 
Dooley  metric. 


Figure  41-5:Dooley  Graph  Window 


41.6.6  The  Dooley  Graph  Engine 

y  I  How  the  Dooley  Graph  engine  works  (in  words).) 

This  section  will  provide  a  short  over  view  of  the  Dooley  Graph  Engine. 

360 

'ckruAry  15/-  1997 


Part  4,  Tool  Strategy 


The  basic  framework  for  doing  the  Dooley  Graph  calculation  is  provided  by  the 
set  of  utterances  defined  in  a  Conversation.  Given  that  the  utterances  have  been 
properly  defined  -  with  regards  to  type  and  the  various  related  utterances,  the  cal¬ 
culation  of  the  Dooley  Graph  proceeds  in  a  very  straight-forward  process. 

The  basic  idea  is  for  each  utterance  to  create  as  set  of  Dooley  Nodes  and  Dooley 
Arcs.  Each  utterance  will  keep  its  list  of  nodes  and  arcs.  Some  utterances  may  only 
create  arcs  while  others  may  create  both. 

Each  utterance  knows  who  is  sending  it  (the  sender),  the  list  of  recipients,  the 
utterance  it  completes  (optional),  resolves  (optional),  or  is  a  response  to  (optional). 
The  application  is  designed  around  this  knowledge  -  the  editors  provide  user  tools 
for  capturing  this  information  and  the  utterances  in  turn  use  this  information  in 
calculating  the  Dooley  Graph. 

The  Conversation  Window  has  a  method  called  /doDooley  that  manages  the  pro¬ 
cess  of  calculating  and  then  presenting  a  Dooley  Graph.  The  method  is  divided  into 
2  major  segments.  The  first  part  of  the  method  calls  another  method  /calcDooIey. 
This  method  creates  an  internal  representation  of  the  Dooley  Graph.  The  rest  of 
the  method  takes  care  of  creating  a  visual  representation  of  the  Dooley  Graph  and 
opens  a  Dooley  Graph  Window  to  display  it. 


iP=^  1:2  Conuersation  UJindom/doDooley  s[^f|iJi[as[jJi| 


«  Conversation  Window  » 


^  /calcpooley  ^  X 


Document  or  NULL 
A  A  .cy 


Figure  41-6:Conversation  Editor/doDooley 
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The  method  /calcDooley  handles  the  calculation  of  the  internal  representation 
of  the  graph.  It  obtains  the  Conversation  instance  by  the  successive  messages  /Get 
Owner  and  /Get  Data.  The  Conversation  instance  is  then  sent  a  message  /doDooley. 
After  all,  its  the  Conversation  object  that  contains  the  utterances  and  actors 


Figure  41-7:Method:  Conversation  Editor/calcDooley 

Now  the  Conversation  object  will  respond  to  the  /doDooley  message  by  first  fig¬ 
uring  out  the  Dooley  parts  (Dooley  Nodes  and  Dooley  Arcs)  in  the  local  method  de- 
fineDooleyParts  If  that  method  succeeds,  it  will  then  create  a  DooleyGraph 
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instance  which  will  be  used  later  in  defining  the  visual  representation  of  the  nodes 
and  arcs  of  the  Dooley  Graph. 


Figure  41  -8:Method:Conversation/doDooley 

The  local  method  defineDookyParts  expects  a  list  of  utterances  a  for  input.  The 
first  utterance  is  special  and  it  is  detached  from  the  list  and  sent  the  message  /do- 
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ForcedDooky.  The  rest  of  the  utterances  are  sent  the  message  /beginDooky.  These 
messages/methods  are  described  next. 


psO  1:1  defineDooleyParts 


0 ;«  utterance  » 


m 


setDooley  Node  index 


detach-nth 


Bill 


m 

1130 


Figure  41  -9:Local:Conversation-defineDooleyParts 

The  goal  of  method  Utterance/doForcedDooky  is  to  create  a  DooleyNode  in¬ 
stance  for  the  sender  and  for  each  receiver  of  the  utterance.  The  method  creates 
a  local  list  composed  of  the  sender  (an  Actor  instance)  and  the  list  of  receivers  (a 
list  of  Actors).  Then  the  method  creates  a  list  of  DooleyArcs  which  pair  up  the  send- 
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ing  DooleyNode  as  the  source  node  and  the  receiving  nodes.  In  other  words,  a 
DooleyArc  is  created  for  each  DooleyNode  pair. 


iP=^  1:t  Utterance/doForcedDooleM 


Bll 


«  Utterance » 


IS 


m[ 

I13@ 


Figure  41-1 0:Method:Utterance/doForcedDooley 


The  other  Utterances  receive  a  /beginDooIey  message.  The  utterance  in  turn 
checks  to  see  if  it  resolves  an  utterance  or  completes  an  utterance.  If  it  does  nei- 
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The  /doDooley  method  in  the  Utterance  class  creates  nodes  and  arcs  in  similar 
fashion  to  /doForcedDooley.  As  in  the  /doForcedDooky,  a  set  of  DooleyNodes  are 
created.  In  /doDooley  however,  the  list  of  DooleyNodes  are  based  only  on  the  set 
of  receivers  (Actors).  The  DooIeyArcs  are  defined  based  on  the  set  of  DooleyNodes, 
but  the  Utterance  object  uses  the  Replies  To  utterance  to  obtain  a  related  node. 
This  related  node  is  used  as  the  Sending  node  when  creating  the  list  of  Dooley 
arcs. 


The  method  Utterance/doOnlyArcs  is  called  for  non-spawning  utterances.  It  ba- 
sically  relates  existing  nodes  using  Dooley  arcs.  The  utterance  queries  the  Replies 
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To  utterance  for  a  list  of  related  nodes  (using  the  Sender  and  list  of  Receiving  ac¬ 
tors  as  a  basis),  and  creates  DooleyArcs  for  each  pair. 


iPi^  1:2  Utterance/doOnlyflrcs  iPilUlla^EJI 


NULL 


^  /getPHodeVith  Actor ; 


^  i 

. . . . V 


^ My  Dooley  Arcs  ^ 

6 


o 


0 


Figure  41-13:Method:  Utterance/doOnlyArcs 


41.6.7  Key  Pomegranate  Classes 

|The  class  structure  of  the  prototype.) 

41.6.7.1  CLASS:  Conversation  Document 

Subclass  of:  Document 
Section:  Agility  Documents 
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Purpose:  Proxdde  file  I/O  support.  Contains  and  instance  of  Conversation. 

Responsibilities:  Save  Con/ersation  Document  to  disk.  Load  a  Conversation  Doc¬ 
ument  from  disk  into  memo  -y.  Provide  dialog  for  user  to  define  Conversation  Doc¬ 
ument  file  name.  Provide  diulog  fo*  user  to  select  a  specific  Conversation 
Document  to  open. 

41.6.7.2  CLASS:  Conversation 
Base  Class 

Section:  Agility  Documents 

Purpose:  Provide  container  for  actors,  utterances  and  Dooley  Graph  objects. 
Manages  calculation  of  Dooiey  Graph. 

Responsibilities:  Provide  method  to  add  an  instance  of  actor.  Provide  method  to 
add  an  instance  of  utterance.  Provide  a  method  to  delete  an  utterance.  Provide 
method  to  support  calculation  of  Dooley  Graph. 

41.6.7.3  CLASS:  Utterance 
Base  Class 

Section:  Agility  Utterances 

Purpose:  Base  class  for  Utterance.  Provides  definition  of  the  sender  of  specific 
utterance,  and  the  set  of  recipients  of  specific  utterance. 

Responsibilities:  Record  who  is  the  sender  of  the  utterance.  Record  who  receives 
the  utterance.  Provide  technique  for  creating  Dooley  Nodes  based  on  the  type  of 
utterance. 

4CLASS:  Utterance  SUBCLASS:  URequest 
Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance. 

^CLASS:  Utterance  SUBCLASS:  URefuse 
Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance. 

^CLASS:  Utterance  SUBCLASS:  UPropose 
Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance. 
iCLASS:  Utterance  SUBCLASS:  UShip 
Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance. 

^CLASS:  Utterance  SUBCLASS:  UPay 
Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance. 

^CLASS:  Utterance  SUBCLASS:  UAssert 
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Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance. 

^CLASS:  Utterance  SUBCLASS:  UCommit 
Section:  Agility  Utterances 
Purpose:  Subclass  of  Utterance, 

41 .6.7.4  CLASS:  Actor 
Section:  Agility  Utterances 

Purpose:  Provides  the  definition  of  a  participant  in  a  conversation. 
Responsibilities:  Capture  name  of  participant  in  a  conversation. 

41.6.7.5  CLASS:  Dooley  Graph 
Base  Class 

Section:  Agility  Utterances 

Purpose:  Contains  Dooley  Nodes  and  Dooley  Arcs  that  result  from  the  calcula¬ 
tion  of  a  Dooley  Graph  (the  algorithm). 

Responsibilities:  Manage  the  generation  of  Dooley  Nodes  and  Arcs  at  the  time  a 
request  is  made  to  perform  the  Dooley  Calculation.  Provide  for  the  generation  of 
display  elements. 

41.6.7.6  CLASS:  Dooley  Node 
Base  Class 

Section:  Agility  Utterances 

Purpose:  Relates  the  Actor  who  owns  the  node  and  the  Utterance  that  creates  the 
node. 

Responsibilities: 

41.6.7.7  CLASS:  Dooley  Arc 
Section:  Agility  Utterances 

Purpose:  Relates  2  Dooley  Nodes  (Source  and  Sink). 

41 .6.7.8  CLASS:  Utterance  Thread 
Purpose:  Experimental 

41.6.7.9  CLASS:  Conversation  Window 
Subclass  of:  Window 
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Section:  Agility  Windows 

Purpose:  Display  the  list  of  Actors,  and  the  list  of  Utterance.  Provides  a  means  to 
add  actors  to  the  conversation  and  to  add/subtract  utterances  to  a  conversation. 
Provides  a  means  to  open  the  utterance  editor  for  a  specific  utterance.  Provides  a 
means  to  start  the  calculation  of  the  Dooley  Graph. 

41.6.7.10  CLASS:  Dooley  Graph  Window 
Purpose:  Displays  the  Dooley  Graph. 

Responsibilities:  Provide  a  GUI  container  for  elements  that  graphically  represent 
a  Dooley  Graph  of  a  Conversation.  Provide  methods  for  inspecting  elements  in  the 
graph  and  moving  elements. 

41.6.7.11  CLASS:  Dooley  Bag 

Purpose:  A  GUI  element  used  in  the  Dooley  Graph  Window  to  represent  a  single 
Dooley  node. 

Responsibilities:  Provide  a  user  interface  mechanism  to  notify  container  window 
of  user  interaction.  Draw  contents  of  Dooley  Bag  in  owning  window. 

41.6.7.12  CLASS:  Dooley  Item 
Purpose:  Experimental 

41.6.7.13  CLASS:  Utterance  Editor 

Purpose:  Provides  a  means  to  edit  a  single  utterance.  Can  specify  the  sender  of 
the  utterance,  the  recipients  of  the  utterance,  and  the  type  of  utterance. 

Responsibilities:  Interact  with  a  specified  Utterance.  Provide  GUI  elements  to 
specify  sender,  recipients  and  type. 

41.6.7.14  CLASS:  Utterance  Grid 
Subclass  of:  GRID 

Purpose:  Displays  Utterance  Row  objects. 

41.6.7.15  CLASS:  Utterance  Row 
Subclass  of:  ROW 

Purpose:  Predefined  collection  of  window  items  organized  such  that  each  Utter¬ 
ance  can  display  its  information  in  the  Conversation  Window  in  the  Utterance  Grid. 
'Each  Utterance  instance  has  a  link  to  a  Utterance  Row  instance.  An  utterance  row 
displays  summary  information  about  each  utterance  -  type,  sender,  recipients  and 
a  summary  string. 
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41.7  Section/Class  Cross  Reference 

[CPX  programs  are  arranged  by  sections.  Here  is  a  class/section  cross-reference.) 

This  section  lists  each  CPX  section  that  has  been  added  to  the  typical  baseline 
ABC  Application.  These  sections  or  files  contain  the  classes/methods/universals/ 
persistants  that  define  the  operation  of  Pomegranate. 

41.7.1  Section:  Agility  Database 

(Classes  of  the  Agility  Database  section.) 

Agility  DB  Manager 
Agility  DB  Specifier 
Enterprise  Window 

41.7.2  Section:  Agility  Documents 

(Classes  of  the  Agility  Documents  section.) 

DooleyGraph  Doc 
Conversation  Document 
Conversation 
Agility  Project  Document 
Agility  Project  Data 
Conversation  File 

41.7.3  Section:  Agility  Preferences 

[Classes  of  the  Agility  Preferences  section.) 

AgilityPrefsOOO 
Agility  Prefs  File 
Agility  Prefs  Window 
Agility  PrefsOOl 

41.7.4  Section:  Agility  Utterances 

[Classes  of  the  Agility  Utterances  section.) 

Actor 

Utterance  Thread 
Utterance 
URequest 
I  URefuse 
UPropose 
UCommit 
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UAssert 

UShip 

UPay 

DooleyArc 

DooleyGraph 

DooleyNode 

41.7.5  Section:  Agility  Windows 

(Classes  of  the  Agility  Windows  section.) 

Bag  Layout 
Utterance  Grid 
Utterance  Row 
Dooley  Bag 
Dooley  Line 
Conversation  Window 
Utterance  Editor 
Dooley  Graph  Window 
Segue  Agility 
Actor  Editor 
Agility  Project  Window 
Conversation  File  Row 
Agility  Window 

41 .7.6  Section:  Agility  Workspace 

[Classes  of  the  Agility  Workspace  section.) 

AgilityMetricsMenu 

EntepriseMenu 

Pomegranate  Edit  Menu 

Pomegranate  File  Menu 

Apple  Menu 

Agility  App 

Help  Menu 

Scroll  View  Task 

Agility  RDF 

Transform 

Hllite  Node  Task 
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42  Dooley  Graph  Algorithm 

IThis  section  details  the  Dooley  Graph  algorithm] 

Information  in  this  section  was  provided  by  the  Industrial  Technology  Institute: 
Van  Parunak 

Industrial  Technology  Institute 
2901  Hubbard  Road 
Post  Office  Box  1485 
Ann  Arbor,  Ml  48106-1485 
Email:  van@iti.org 
Web:  http:/Avww.iti.org 
Fax:  313/769-4064 

42.1  What  is  a  Dooley  Graph? 

[The  procedure  is  given  here.) 

Formally,  a  Dooley  Graph  is  generated  by  a  4-tuple  <E,  P,  M,  A>,  where 

E  =  {1, 2,  ...,  n}  is  a  set  of  counting  numbers  indexing  the  chronologically  or¬ 
dered  (or  at  least  orderable)  utterances  in  the  conversation; 

P  =  {p ,  p . p  }  is  the  set  of  participants  in  the  conversation; 

A  =  {<p,  p,  k>:  <p,  k>  (S  &  <k,  p>  (R}  is  a  set  of  ordered  triples,  defined 
with  the  aid  of  two  sets  of  ordered  pairs  over  E  and  P:  the  Sender  set  S  =  {<p, 
k>:  participant  p  sends  utterance  k},  and  the  Addressee  set  R  =  {<k,  p>:  partic¬ 
ipant  p  receives  utterance  k}.  (The  notation  R  reflects  Dooley’s  use  of  the  word 
recipient  rather  than  Addressee,)  There  is  no  assumption  that  each  utterance  has 
only  one  sender  and  one  addressee.  However,  we  do  assume  that  there  is  no  pro¬ 
miscuous  eavesdropping.  Each  triple  in  A  will  become  an  arc  in  the  Dooley  Graph. 

M  is  a  relation  from  S(R  to  S(R,  which  generates  the  vertices  of  the  graph  and 
indicates  which  arcs  (utterances)  are  linked  at  which  vertices.  It  is  subject  to  the 
restriction  that  whenever  two  ordered  pairs  are  M-related,  their  P  coordinates 
must  be  the  same.  That  is,  M  may  relate  two  utterances  if  either 

4 the  two  are  sent  by  the  same  participant, 

4the  two  are  addressed  to  the  same  participant, 

4the  addressee  of  the  first  sends  the  second,  or 
4  the  addressee  of  the  second  sent  the  first. 

M  may  relate  two  utterances  under  these  conditions.  Whether  it  actually  does 
or  not  depends  on  the  particular  discourse  theory  that  one  wants  to  represent  in 
M.  M  is  the  mechanism  by  which  the  vertices  of  the  graph  are  defined.  The  same 
participant  requirements  above  will  ensure  that  each  node  in  the  graph  corre- 
^sponds  to  a  single  participant,  while  the  restrictions  imposed  by  the  discourse  the- 
'oiy  keep  all  instances  of  a  single  participant  from  collapsing  into  a  single  vertex. 
Within  the  bounds  of  this  restriction,  we  can  expect  to  do  considerable  experimen- 
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tation  with  the  actual  definition  of  M  to  provide  graphs  with  the  right  balance  of 
state  and  participant  information. 

Dooley  originally  suggested  the  condition  that  <i,p>M<pj>  iff  any  of  three 
conditions  is  met: 

replies  to  i, 

^i  replies  to  and  resolves], 

^i  replies  to]  and  is  the  last  utterance  in  the  conversation. 

To  capture  the  information  in  the  completes  relations  between  utterances,  1  add 
a  fourth  option: 

^i  completes  k  and  k  replies  to  and  resolves]. 

Thus  completion  becomes  a  way  for  utterances  to  inherit  resolution  from  one 
another.  This  definition  does  not  capture  any  information  from  the  resolves  rela¬ 
tion. 

[PARU96b]  discusses  why  resolves  is  needed,  shows  why  it  difficult  to  capture  it 
in  the  M  relation,  and  suggests  a  solution  that  augments  the  basic  Dooley  Graph. 

We  move  from  <E,  P,  M,  A>  to  a  graph  by  the  following  steps. 

^Define  an  equivalence  relation  N  over  S(R  by  first  copying  M  into  N,  then  closing 
N  under  symmetry,  reflexivity,  and  transitivity,  (If  aNb,  add  bNa,  aNa,  and  bNb.  If 
aNb  and  bNc,  add  aNc.  Repeat  until  there  are  no  further  additions  to  N.) 

induces  a  partition  V  =  (S(R)/N  of  S{R.  The  elements  of  V  are  the  vertices  of 
the  graph.  The  P  coordinates  of  all  the  members  of  any  one  element  of  V  are  the 
same  (though  there  may  be  several  vertices  representing  a  given  participant),  and 
are  labeled  by  their  P  coordinate  and  an  appropriate  index.  The  arcs  of  the  graph 
are  the  triples  in  A.  For  <pj,pj,k>  (A,  there  exist  unique  members  v,  v  ofV  that 
contain  <p,  k>  and  <p,  k>,  respectively,  and  an  arc  labeled  k  is  drawn  from  v, 
to  V .  Intuitively,  a  participant  moves  from  one  vertex  to  another  when  control  of 
the  conversation  changes,  that  is,  when  another  participant  replies  to  a  solicit 
with  other  than  the  act  expected  by  the  solicit,  or  otherwise  initiates  a  new 
thread.  Thus  a  conversation  in  which  every  participant  knows  its  place  and 
speaks  only  when  spoken  to  appears  as  a  graph  with  only  one  node  per  partici¬ 
pant,  while  a  free-for-all  spawns  long  chains  that  represent  participant’s  attempts 
to  gain  control  of  the  conversation. 

42.2  An  Example 

(An  illustrative  example  is  presenteci.j 
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As  an  illustration,  we  develop  the  Dooley  Graph  for  the  example  conversation  in 
Part  1. 


Sequence 

Sender 

Receiver 

Utterance 

Speech  Act 

Responds  to 

Replies  to 

Resolves 

Completes 

D 

B. 

D.C 

Please  send  me  50  widgets  at  your  catalog 
price  by  next  Thursday 

Request 

■ 

■ 

1 

■ 

B 

C 

Are  you  bidding  on  A’s  RFQ? 

■ 

■ 

■ 

C 

B 

Yes,  1  am 

Inform 

2 

2 

2 

■ 

B 

A 

1  no  bid 

Refuse 

3 

1 

1 

■ 

5  « 

C 

A 

How  about  40  widgets  at  catalog  price  by 
next  Friday? 

Inform, 

Request 

1 

1 

1 

B 

C 

Please  send  me  40  widgets  at  catalog  price 
by  next  Friday 

Request 

5 

5 

5 

h 

C 

A 

1  plan  to  send  you  40  widgets  at  catalog 
price  by  next  Friday 

Commit 

6 

6 

6 

8! 

D 

A 

1  plan  to  send  you  50  widgets  at  catalog 
price  by  next  Thursday 

Commit 

1 

9  1 

D 

C 

I’ve  found  a  better  supplier,  and  am  not  rely¬ 
ing  on  your  Commit 

Assert 

7,8 

■ 

■ 

B 

lo” 

C 

A 

1  am  abandoning  my  Commit 

Refuse 

9 

9 

■ 

B 

D 

A 

Here  are  your  widgets.  Please  pay  me 

Ship 

1 

1 

■ 

12 

D 

D 

You  are  five  short.  Please  send  the  differ¬ 
ence 

Assert, 

Request 

11 

11 

1 

■ 

D 

A 

Here  are  five  more  widgets,  Please  pay  me. 

Ship 

12 

12 

12 

■ 

~ 

D 

D 

Here’s  your  moola 

Pay 

13 

13 

13 

■ 

Table  42-1:  Breakdown  of  an  Example  Process 


By  examination, 

iE  =  {1.  2,  3, 4.  5.  6,  7,  8, 9. 10,  1 1, 12, 13, 14} 

4P={A,  B,  C,D} 

4A  =  {<A,B,1>,  <A,C,1>,  <A,D,1>,  <B,C,2>,  <C,B,3>,  <B,A,4>,  <CA5>, 
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<A.C,6>,  <CA7>,  <DA8>.  <A,C,9>,  <CA10>,  <DA11>,  <AD,12>, 
<DA13>,  <AD,14>} 

The  construction  of  M  is  the  least  intuitive  part  of  the  process.  To  help  clarify  it, 

I  will  develop  M  in  four  parts,  corresponding  to  the  four  eligibility  conditions  a-d 
outlined  above  for  <i,p>M<p,j>.  To  simplify  the  notation,  I  write  ‘IB’  for  the  ad¬ 
dressee  pair  <1,B>,  ‘B2’  for  the  sender  pair  <B,2>,  and  similarly  for  other  utter¬ 
ances  and  participants. 

is  a  reply  to  i:  M.=  {<2C,C3>,  <1B,B4>,  <1C.  C5>,  <5A,A6>,  <6C,  C7>, 
<1D,  D8>,  <7A,A9>,  <9C,C10>,  <1D,  D11>,  <11A.A12>,  <12D,D13>, 
<13A.A14>} 

^i  replies  to  and  resolves  j:  M,  =  {<3B.  B2>,  <4A,  Al>,  <6C,  C5>,  <7A,A6>, 
<8A,A1>,  <13A,A12>,  <14D,  D13>} 

^i  replies  to  j  and  is  the  last  utterance  in  the  conversation:  M.  =  {<14D,  D13>} 
(already  included  in  MJ. 

4i  completes  k  and  k  replies  to  and  resolves  j:  Mg  =  {<10A,  A6>,  <11A,  A1  >} 
The  resulting  partition  of  S(R  is 

=  {A,  A,  B.  B,  C,  C,  C,  D,  D },  where 
=  {4A,A1,8A,  llA,  A12,  13A,A14}, 

4A2=  {5A.A6,  7A.A9,  lOA}, 

^B,  =  {1B.B4}. 

4B2  =  {B2,  3B}, 

4C]  =  {1C,C5.6C,C7}, 

^C2  =  {9C.  CIO}, 

^C3  =  {2C.  C3} 

^Di  =  {ID,  D8,  Dll}, 

^D2  =  {12D,  D13,  14D}. 

The  figure  shows  the  resulting  Dooley  Graph.  Several  components  of  this  graph 
invite  discussion.  I  will  label  components  by  sets  of  vertices,  and  include  by  refer¬ 
ence  all  edges  among  those  vertices. 

^The  conversation  originates  in  {A,  B,,  C,  D  }  as  A  broadcasts  a  request  to  its 
trading  partners  B,  C,  and  D.  B  and  D  respond  as  expected,  resolving  A’s  request 
with  a  refuse  and  a  commit  respectively,  so  their  responses  remain  within  the  orig¬ 
inal  component.  Because  D’s  original  ship  (utterance  1 1)  completes  its  commit 
(utterance  8),  the  ship  is  also  part  of  this  component. 

does  not  accept  the  terms  of  the  discussion.  Its  propose  (utterance  5)  does 
not  resolve  A’s  original  request,  spawning  a  new  component,  {C,  A.},  in  which  C 
and  A  agree  on  new  terms,  leading  to  a  commit  by  C  at  utterance  7. 

^A  sidebar  conversation  between  B  and  C  before  B’s  decision  not  to  bid  (utter- 
'  ances  2  and  3)  generates  a  separate  component  of  the  graph  (Nodes  B,  and  C, 
utterances  2  and  3).  This  component  is  separate  because  none  of  its  utterances 
replies  to  or  completes  any  of  those  in  the  main  component.  We  can  integrate  it 
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Figure  42-1  :The  Example’s  Dooley  Graph 


with  the  rest  of  the  graph  by  using  information  from  the  responds  relation,  but 
there  are  trade-offs,  discussed  in  the  next  section. 

^The  numbering  of  the  utterances  shows  that  D’s  commit  (utterance  8)  arrives 
after  C’s  (utterance  7).  Because  D’s  commit  matches  A’s  original  request  while  C’s 
does  not,  A  cancels  the  arrangement  with  C  in  utterance  9.  This  utterance  does 
not  resolve  any  utterances  in  {C ,  A},  and  so  initiates  a  new  component,  {A,  C}, 
a  topological  reflection  of  the  discontinuity  that  such  a  withdrawal  represents  in 
the  overall  conversation. 

^A’s  conversation  with  D  also  spawns  a  new  component,  {A ,  DJ,  when  A  finds 
D’s  initial  ship  (utterance  11)  deficient.  Again,  the  topology  of  the  graph  captures 
the  discontinuity  in  the  expected  course  of  the  conversation. 
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43  Turnip  and  the  Topology  Perspective 

|We  note  that  we  have  a  proprietary  approach  which  generalizes  the  metrics  approach  to  other  analytical  and 
representational  areas.) 

Sirius-Beta  has  two  core  competencies.  One  is  in  broad  interdisciplinary  ap¬ 
proaches  to  novel  architectural  problems  dealing  with  enterprise  infrastructure 
and  emerging  commercial  enablers.  The  Metrics  Project  taxes  this  expertise,  which 
has  produced  this  report.  But  there  is  a  related  strength  which  relates  to  the  Tool 
Strategy.  It  is  the  subject  of  this  section. 

Concerning  the  other  strength,  prior  work  has  focused  on  a  novel  approach  to 
conceptual  indexing  which  is  related  to  the  method  we  used  in  devising  the  met¬ 
rics.  There,  we  characterize  action  using  the  conceptual  types  of  performatives 
and  work  with  a  few  simple  topological  characteristics  (the  complexity  of  the  con¬ 
versation,  the  process)  to  linearly  (meaning  quantitatively)  index  one  of  its  charac¬ 
teristics  (its  ability  to  adapt). 

In  the  more  general  approach,  we  can  use  a  variety  of  characterizations,  work 
with  more  complex  topological  characteristics,  and  index  many  characteristics 
multidimensionally.  We'll  just  briefly  note  each  of  these,  then  suggest  how  the 
Tool  Strategy  is  affected. 

43.1  Federated  Representations 

(Syntactic  abstraction,  the  form  of  the  information,  as  a  lever  for  federating  diverse  representations.) 

Several  studies  have  indicated  the  importance  of  model  federation.  This  is  the 
situation  where  diverse  parties  each  have  their  own  representation  system  (mod¬ 
els,  languages,  ontologies...),  have  control  over  those  representations,  but  can  col¬ 
laborate  as  if  they  all  had  the  same  representations.  A  presumption  is  that  this  is 
desirable,  as  in  the  case  of  the  AVE,  where  great  stren^hs  in  partnering  often  re¬ 
sult  from  seeking  a  partner  who  radically  differs  from  you. 

We  salute  this  goal  and  accommodate  it  in  the  metrics,  but  in  a  way  that  effec¬ 
tively  avoids  the  problem.  We  can  extract  the  performatives  we  need  from  many 
representational  schemes,  and  substantial  work  has  been  done  in  this  regard  by 
knowledge  sharing  researchers.  But  our  case  study  indicates  that  the  cheapest 
route  is  simply  to  remodel  the  few  processes  of  interest  directly  in  the  performa¬ 
tives,  which  in  other  contexts  would  be  considered  an  intermediate  form. 

Two  other  agility  projects  more  directly  address  the  federation  problem,  taking 
different  compromises.  As  we  link  with  one  or  both  of  these,  we  will  too. 

In  a  manufacturing  enterprise,  the  problem  of  federation  is  exacerbated  by  the 
necessity  of  some  parts  of  the  organization  to  control  other  parts  with  sensitivity 
to  both  an  absolute  and  a  state  vision  of  time.  Standards  are  not  the  answer,  that 
just  stamps  out  the  diversity  we  want  to  encourage. 

One  answer  appears  to  be  metastandards.  Instead  of  trying  to  get  all  the  nations 
^on  the  Tower  of  Babel  project  speaking  the  same  language,  better  to  have  all  those 
languages  mapped  to  a  common  model.  (Metastandards  for  languages  need  to  be 
models,  for  models,  languages.) 
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Good  work  toward  this  goal  has  been  done  by  the  Semantic  Unification  Meta 
Model  [FULT921  standard-related  effort.  But  even  if  that  were  extended  to  handle 
dynamics,  there  is  a  lot  of  work  to  be  done  in  normalizing  the  target  languages  and 
registering  each  with  the  metamodel.  The  world  is  not  so  kind  as  to  make  this  even 
remotely  thinkable. 

But  what  If  the  detailed  semantics  of  the  languages  became  less  important.  Sup¬ 
pose  syntactic  structure  was  emphasized?  This  is  not  a  trick  question.  The  seman¬ 
tic  content  of  a  statement  Is  Its  meaning.  The  syntax  merely  how  the  meaning  is 
packaged.  It  would  seem  only  common  sense  that  the  syntax  is  unimportant.  But 
consider  a  few  cases: 

^1  have  a  dog  who  seems  to  understand  all  the  important  commands.  He  has  no 
Idea  what  the  semantics  of  those  commands  are.  It  seems  likely  that  he  has 
learned  a  few  words  by  sound,  for  instance  his  name.  But  what  he  picks  up,  he 
gets  from  the  way  I  say  things,  including  body  language. 

Now,  there  are  terrible  arguments  over  whether  this  wrapper,  my  movements  and 
voice  inflections,  constitute  indirea  or  supplemental  semantics.  But  they  are  In 
the  category  that  we  prefer  to  call  syntactic. 

^The  intelligence  community  is  interested  in  this  kind  of  syntax.  It  may  be  more 
important  that  mobilization  command  messages  are  going  from  headquarters  to 
the  field  than  what  the  detailed  contents  of  all  the  messages  are.  In  fact,  often 
such  details  are  distracting  from  the  most  important  meaning.  The  best  example 
is  that  the  roughly  2  trillion  dollars  spent  on  understanding  the  Soviet  Union  gen¬ 
erated  a  great  many  details,  but  still  missed  predicting  the  event  of  the  century, 
its  sudden  collapse. 

Syntactic  abstraction  looks  at  the  form  of  information  to  get  some  meaning  from 
it.  Internet  crooks  already  have  excellent  profiles  to  determine  whether  a  mes¬ 
sage  is  an  order  that  is  likely  to  contain  credit  information.  These  kinds  of  profil¬ 
ers  are  in  use  (by  others)  to  categorize  all  sorts  of  messages.  It's  the  basis  of  vast 
indices. 

^Imagine  that  we  are  not  talking  about  military  messages,  but  their  components, 
concepts.  If  we  can  normalize  these  concepts  into  a  single  form,  like  we  did  hand¬ 
ily  with  the  performatives,  we  could  index  some  features  about  their  syntax. 

But  suppose  that  different  forms  exposed  different  features  worthy  of  Indexing, 
which  means  each  concept  would  be  mapped  into  a  number  of  different  forms. 
Also  suppose  that  the  sources  weren't  presented  to  you  in  a  uniform  format.  In  the 
intelligence  domain,  they  could  be  messages  in  a  different  languages,  human  and 
machine.  They  could  be  unstructured  parameters  such  as  the  number  of  tanks  or 
grain  yield  at  a  certain  place;  or  images;  or  parametric  streams  like  financial  trans¬ 
actions,  and  the  semantics  may  not  be  available  to  you  in  any  case  because  of  en¬ 
cryption  (which  only  really  affects  semantics). 

I  Then  you'd  be  mapping  many  source  forms  against  many  normalizing  syntax 
representations.  This  is  a  real  mess.  That  is,  unless  you  had  a  viable  metamodel  for 
all  normalizing  representations.  Then  you  might  not  have  the  dozens  or  hundreds 
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or  millions  of  mappings  (like  the  performctives)  ail  prefabricated.  You  might  in¬ 
stance  them  on  the  fly.  In  fact,  you  might  not  really  instance  them,  instead  just 
note  how  they  might  be  instanced  from  the  metamodel. 

Moving  from  a  representation  to  a  useful  categorizing  abstraction  of  any  sort  is 
type  abstraction,  a  fairly  well  understood  discipline,  something  that  is  done  ail  the 
time.  But  a  reader  might  understand  that  what  weVe  described  is  doable,  but  ab¬ 
solutely  useless.  We'd  be  taking  things  that  are  relatively  simple,  that  probably  re¬ 
late  in  some  intuitive  way  to  the  real  world,  and  which  have  meaning.  And  we'd  be 
replacing  that  with  many,  many  (arbitrarily  many  manys  here)  representations  that 
are  less  intuitive,  less  connected  to  the  phenomena  of  interest.  Why  would  we  do 
such  a  thing?  It's  the  computer  science  problem  from  hell. 

The  answer  is: 

4We  get  leverage  on  the  federation  problem.  If  we  throw  model  needs  Into  the 
leverage  pot,  we  can  federate  into  solution  domains.  We  did  this  in  our  naive  ver¬ 
sion  of  the  process  with  the  metrics,  federating  process  models  into  parametric 
models. 

^The  amazing  complexity  of  the  method  is  manageable  because  we  can  express 
each  type,  each  abstraction  relationship,  each  metamodel  and  each  metarelation¬ 
ship  in  the  same  simple  language  and  deal  with  them  all  by  applying  functions 
wholesale,  over  patterns  or  clusters  of  them. 


43.2  Categorical  Types 

[Some  tricks  to  abstracting  that  enable  the  approach.] 

There  are  a  multitude  of  ways  to  define  types  and  attitudes  about  what  they  rep¬ 
resent.  We  simplify  our  type  universe  by: 

^Insisting  on  categorical  types.  Category  Theory  [AL911  (CROL93]  [MACL711is  a 
theory  of  typing  functions.  So  by  insisting  on  types  as  narrowly  defined  there,  we 
end  up  with  elements  specifically  designed  for  functional  indexing.  All  we  have  to 
do  is  be  moderately  careful  about  the  relationships  between  models  and  lan¬ 
guages,  and  we're  halfway  toward  concept  indexing.  Category  Theory  is  espe¬ 
cially  useful  in  that  one  can  recast  formalisms  in  it  normally  based  in  set  theory, 
the  default  for  modelers  and  logicians.  This  means  that  we  can  see  not  only  the 
types,  but  the  language  syntax  from  which  these  types  were  abstracted  in  cate¬ 
gorical  terms.  Very  important  for  the  reflection  noted  below. 

^Requiring  that  the  functions  have  topology  in  the  abstraction  (the  type)  space. 
An  example  of  a  simple  topology  was  the  node/loop  topology  we  leveraged  in  the 
Dooley  Graphs.  There  the  types  were  based  on  both  the  notion  of  state  and  per¬ 
formative  to  reveal  the  syntactical  topology.  We  need  the  topological  syntax  for 
two  reasons 

4We'll  be  typing  (abstracting)  from  the  types  an  arbitrary  number  of  times. 
This  means  that  there  has  to  be  syntax,  abstractable  representation 
structure,  at  both  ends.  This  is  guaranteed  by  limiting  the  types  to 
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topological  abstractions. 

^We'll  want  to  dive  in  at  any  point  in  our  representation  (or  meta-  or 
metametarepresentation)  and  use  it  for  analysis.  The  analysis  will  be  on 
syntax,  of  the  same  nature  as  our  node/loop  counting.  In  other  words,  we 
want  to  be  able  to  vectorize  any  concept  at  any  level  of  abstraction  (a 
vector  being  just  a  linearization  of  a  topological  feature),  and  work  with 
bundles  and  fibers  (for  instance)  to  give  us  concept  clustering  or  pattern 
matching.  This  also  is  guaranteed  by  limiting  the  types  to  topological 
abstractions. 

Note  that  our  efforts  with  Situation  Theory  will  bringing  soft  context  into 
the  same  type  structure  as  first  class  objeas. 

43.3  Symmetry  Grammars 

|A  novel  representation  space  based  on  group  theory  and  topological  features  of  syntax.) 

We  are  faced  with  vast  numbers  of  types,  type  fragments  and  abstraction  state¬ 
ments,  together  with  whatever  administrative  information  is  included.  (This  infor¬ 
mation  is  treated  the  same  as  all  the  rest  which  is  to  say  it  is  both  something  about 
the  system  and  a  constituent  of  the  system.)  But  we  pulled  a  trick  we  didn't  men¬ 
tion  earlier.  When  constraining  the  type  abstraction  strategy  to  topological  syntax, 
we  constrain  to  certain  types  of  topological  features. 

We  use  the  device  of  a  semantic  network  for  interrelating  features,  as  do  many 
folks.  (Of  course  we  don't  store  the  semantics  of  the  concept,  but  a  semantic  rep¬ 
resentation  of  its  syntax,  as  we've  noted.)  We  constrain  the  structure  of  the  nets 
to  lattices,  regular  periodic  lattices.  Such  structures  have  symmetries,  as  do  the  el¬ 
ements  which  populate  it. 

We  exploit  these  symmetries  by  constraining  the  topological  features  we  ab¬ 
stract  to  the  symmetrical  structures  of  the  representation  space.  What  we  are 
faced  with  then  is  a  vast  amount  of  information  which  is  expressed  by  location  on 
a  simple  lattice  (usually  of  high  dimension).  What  it  is  can  be  described  in  simple 
statement  using  a  few  symmetry  statements.  What  its  relationship  to  any  other  el¬ 
ement  can  be  described  in  the  same  symmetry  primitives. 

Indeed,  those  primitives  form  a  grammar  of  sorts  that  describe  transforms,  clus¬ 
ters,  patterns,  mappings,  essentially  anything  you  need  to  support  analysis  (by  ag¬ 
gregation  and  abstraction)  and  presentation. 

There  Is  a  cost  to  such  an  exotic  representational  framework.  But  since  the  over¬ 
head  is  constant  as  the  complexity  of  Its  contents  Increase,  it  becomes  increasingly 
cheaper  as  the  situations  become  sufficiently  complex  to  be  real  and  useful. 

We've  spent  substantial  energy  examining  benefits  of  differing  symmetries,  dif¬ 
fering  dimensions  and  the  useful  transitions  between  them  (IALV77J  |LALV90j. 
^Transforms  among  the  lattice  can  both  be  coded  in  the  lattice  and  affect  the  laws 
of  the  lattice. 
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But  we  haven't  spent  much  time  on  analytical  interfaces.  Fortunately,  group  the¬ 
ory  and  symmetry  are  intrinsic  to  many  disciplines  and  analytical  approaches,  both 
on  the  hard  and  soft  sides.  We  believe  that  a  promising  approach  linearizes  the 
complexities  of  groups  into  graphs,  and  leverages  well  established  techniques  in 
the  graph  theoretical  community  [I^HL951.  These  folks  know  how  to  deal  simul¬ 
taneously  with  terms  and  metaterms  denoting  types  and  metatypes  in  a  normal¬ 
ized  space. 

43.4  A  Powerful  Extension  of  the  Tool  Strategy 

|How  this  is  reflected  and  exampled  in  Turnip.) 

This  all  sounds  exotic,  and  it  is.  It's  a  novel  general  conceptual  federation,  index¬ 
ing  and  manipulation  scheme  for  complex,  dynamic  situations.  What  might  this 
mean  for  our  present  problem?  Turnip  is  an  example  of  how  this  might  be  put  to 
use. 

What  we  do  in  Turnip  is  the  simplest  case.  The  purpose  is  to  interface  to  a  large 
case  base,  such  as  the  MIT  Case  Base,  or  a  similar  repository  in  a  large  consulting 
firm.  We  could  federate  to  many  diverse  case  pools.  We  index  salient  features  of 
their  processes;  in  the  present  case  their  systemic  adaptability  (agility)  is  what  in¬ 
terests  us. 

We  normalize  those  features  into  vectors  and  constrain  the  topology  along  di¬ 
mensions  defined  by  our  internal  agility  metric.  These  become  fiber  bundles, 
whose  characteristics  and  density,  can  be  browsed  by  a  planner.  Where  the  density 
is  high,  it  means  that  many  concepts  are  clustered,  that  there  are  similarities. 

Depending  on  what  you've  constrained,  you  could  look  for  similar  conditions  or 
responses  and  they  would  show,  shorn  of  distracting  context.  You'd  then  click  on 
a  column  (the  fiber  bundle's  Turnip  representation)  and  go  to  the  case  base  index, 
the  Mashed  Potatoes  system  tool  or  a  Pomegranate-like  (or  ISTl  or  KBSl)  process 
analysis  tool. 

All  of  the  exotic  topological  dynamics  are  hidden  from  the  user.  We've  spend 
some  time  at  BAST  studying  the  topology  of  Situation  Theoretic  statements.  We 
believe  that  as  we  move  forward  in  the  soft  mathematics  agenda,  these  can  be  in¬ 
corporated  in  the  symmetry  field. 
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44  Integrating  with  Other  Strategies 

(We  went  far  in  arranging  ways  to  coordinate  with  other  projects.  Here's  how.) 


44.1  The  MIT  Case  Base 

|They  use  the  same  type  of  performative  basis  we  do.  We  believe  their  front  end  can  incorporate  our  general 
evaluative  approach.) 

The  MIT  Case  Base  is  being  performed  by  two  labs  in  MIT.  The  Sloan  School  part 
is  parsing  enterprises  into  process  components  and  storing  them  in  a  database. 
Fortunately  for  us,  this  breakdown  is  being  done  using  a  communicative  act  (in 
their  terms  a  collaborative  act)  breakdown.  We  believe  that  a  mapping  can  readily 
be  made  between  the  projects  so  that: 

^each  stored  process  in  the  handbook  can  have  an  Intrinsic  agility  metric  applied 
to  it,  depending  on  context.  MIT  appears  to  believe  that  there  are  a  finite, 
describable  set  of  contexts.  If  this  is  so,  the  metrics  can  be  stored  with  the  pro¬ 
cess. 

i  Patterns  of  processes  with  predictable  agility  can  be  detected  to  generate  a  list 
of  rules  of  thumb  for  specific  uses. 

The  other  part  of  the  MIT  project  is  being  conducted  by  the  Artificial  Intelli¬ 
gence  Lab;  this  part  deals  with  facilitated  user  interfaces  to  the  case  base.  Since  we 
have  been  careful  to  build  reflective  capabilities  into  the  method,  we  can  support 
an  evaluative  a  component  in  this  part. 

Reflection  is  the  ability  of  a  language  or  model  to  see  and  comprehend  itself.  It 
is  important  when  you  have  something  like  information  infrastructure  which  is 
used  for  dynamic  replanning  and  response.  When  used  in  this  dual  mode,  the  in¬ 
frastructure  is  both  part  of  the  enterprise  in  the  sense  that  it  is  part  of  the  control 
system,  and  outside  of  the  enterprise  in  that  it  analysis  it  as  a  separate  set  of  phe¬ 
nomena. 

We  plan  on  working  with  MIT  as  we  examine  the  reflective  effects  of  second  or¬ 
der  agility. 

44.2  The  ARRI  Method 

|We  detail  how  our  metrics  can  be  incorporated  above.) 

The  Automation  and  Robotics  Research  Institute  of  the  University  of  Texas  at  Ar¬ 
lington  hosts  the  NSFs  Aerospace  Agile  Manufacturing  Research  Center.  They  have 
a  method  for  enterprise  engineering  which  is  described  above.  We  used  them  as  a 
surrogate  for  the  typical  advanced  consultant  that  we  expect  to  find  working  in  the 
defense  aerospace  community.  Our  metrics  fold  logically  into  their  method.  We 
believe  this  approach  should  work  in  the  general  case  as  a  tool  for  agility  that  al¬ 
lows  simultaneous  evaluation  of  agility  with  other  strategic  factors. 

^44.3  The  ISTI  and  KBSl  Agility  Modeling  Workbenches 

(The  KBSl  link  is  based  on  Situation  Theory,  with  ISTI  some  collaborative  planning  meetings.) 
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The  agility  initiative  funds  two  complementary  modeling  projects  by  Intelligent 
Systems  Technology  and  Knowledge  Based  Systems.  The  KBSI  workbench  Is  delib¬ 
erately  based  on  the  conventional,  ontological  use  of  Situation  Theory.  We  feel 
confident  that  BAST2  will  provide  a  strategy  for  subsetting  our  logical  statements 
so  that  all  actons  are  expressible  in  pure  Infon  terms.  This  will  allow  us  to  readily 
communicate  with  the  KBSI  tool  as  a  plugin. 

The  ISTl  tool  is  Interesting,  since  it  is  being  built  from  scratch  for  federation  of 
different  systems  and  in  a  federated  way.  The  tool  is  object  oriented.  There  is  no 
major  architectural  feature  that  makes  our  tools  congruent,  but  we  have  met  sev¬ 
eral  times  at  their  lab  and  have  a  strategy  for  integrating  Pomegranate  as  a  plugin 
tool  for  customers  who  wish  it. 

44.4  The  WTI  Effort 

(The  focus  here  is  on  the  BAST  results.) 

The  Work  and  Technology  Institute  has  been  working  the  union  of  social/cultur¬ 
al  issues  with  manufacturing  technology  and  performance.  Within  the  selection  of 
sponsored  agility  projects  they  are  the  soft  experts.  WeVe  conducted  two  work¬ 
shops  at  their  site,  and  they  have  been  active  participants  In  BAST. 

We  think  that  they  will  be  using  Rosenberg's  Layering/Zooming  approach  {DR96] 
regardless  of  any  collaboration  with  us.  This  makes  it  quite  easy  to  interface  with 
the  family  of  tools  that  have  Situation  Theoretic  expression. 

44.5  The  Autonomous  Agent  Project 

[The  performative  breakdown  can  provide  for  intimate  integration.) 

One  of  the  more  novel  agility  projects  advances  the  technique  of  using  emer¬ 
gent,  self-organizing  behavior  of  autonomous  agents  to  control  elements  of  the 
AVE.  This  has  a  long  way  to  go,  but  it  is  a  potentially  revolutionary  approach.  The 
partner  on  this  project  which  is  looking  at  foundations  for  a  larger  scope  is  the  In¬ 
dustrial  Technology  Institute  (ITI). 

We've  worked  veiy  hard  to  be  able  to  merge  with  this  approach  when  tools 
emerge.  ITI  was  the  partner  on  the  team  which  specified  the  performatives  and  in¬ 
dicated  the  use  of  the  Dooley  Graph. 

Moreover,  since  our  advanced  phase  concerns  the  use  of  actions  (agent-based 
actons)  we  involved  ITI  in  BAST.  Indeed,  ITI  facilitate  BAST96.  We  feel  confident 
that  the  way  is  clear  for  future  collaboration  that  involves  the  future  of  their  per¬ 
formative-based  agent  work,  our  Situation  Theoretic  soft  modeling,  and  the  met¬ 
rics. 

44.6  The  AIMS  Software 

}  [Lockheed  uses  and  agent-based  performative  system,  as  do  we.) 

Agile  Infrastructure  for  Manufacturing  Systems  (AIMS)  is  an  ambitious  project 
led  by  Lockheed  Martin,  which  we  expect  to  lead  to  commercial  software.  The  cen- 
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tral  component  of  the  collaboration  software,  MECE,  is  evolved  from  DARPA  spon- 
worif  collaboration  which  in  turn  depends  on  DARPA  knowledge  sharing 

This  work  is  based  on  speech  performatives,  as  are  the  metrics.  Our  breakdown 
of  acts  IS  more  sparse  than  that  used  by  MECE,  which  is  good  news.  We  should  be 
able  to  easily  interface  our  reflective  metrics  to  their  internal  breakdown  of  pro¬ 
cess  performatives. 

44,7  Commercial  Federation  Strategies 

IDescribes  the  new  notion  of  Design  Patterns,  why  we  wanted  to  use  them,  and  why  we  decided  not  to.) 

We  originally  wanted  to  cast  the  implementation  of  the  metrics  in  the  form  of 
software  patterns.  We  felt  that  this  would  be  the  fastest  way  of  communicating  an 
implementation  strategy  for  widespread  use.  (We  describe  patterns  below.)  This  is 
the  only  element  of  the  project  that  fell  short  of  expectations. 

Instead,  we  ended  up  implementing  an  example  prototype.  Pomegranate,  to  de¬ 
scribe  and  demonstrate  the  class  structure.  In  interviewing  potential  tool  Imple¬ 
mentors,  this  was  considered  substantially  more  useful,  even  though  substantially 
more  effort  was  required  to  create  a  working  prototype. 

44.7.1  Background  of  Patterns 

[What  Design  Patterns  are.j 

In  the  seventies,  Christopher  Alexander  developed  a  theory  of  patterns  for  solv¬ 
ing  design  problems  In  architecture  [ALEX71|  (AIS77)  (ALEX79J.  To  quote  his  defi¬ 
nition: 

“Each  pattern  describes  a  problem  which  occurs  over  and  over 
again  in  our  environment  and  then  describes  the  core  of  the  solu¬ 
tion  to  that  problem  in  such  a  way  that  you  can  use  this  solution  a 
million  times  over,  without  ever  doing  it  the  same  way  twice.” 

While  popular  in  architecture  schools,  the  approach  never  caught  on  in  practice. 
There  is  a  similarity  between  this  domain  and  software  for  business: 

4There  is  a  distinct  division  among  the  three  major  communities:  those  who 
design  the  buildings  (or  business  tools);  those  who  construct  the  environment  (or 
build/manage  the  enterprise);  and  those  who  use  the  environment  (or  conduct 
business). 

^There  is  a  notion  of  style  among  designers  which  doesn't  result  in  apparent  user 
benefits 

4The  users  In  fact  are  quite  ordinary  people  with  very  superficial  insight  (in  most 
cases)  into  details  of  the  system 

4The  results  permeate  life,  concerning  much  of  the  daily  activity  of  essentially  all 
people. 
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These  similarities  were  not  lost  on  the  software  community  who  found  Alex- 
fjnnf  applicable  to  software  design,  especially  in  objert  oriented  situa- 
.  he  idea  has  become  enormously  popular  in  the  object  oriented  community 
spawning  numerous  books  (CS95J  (GHJV95)  (PREE94|  papers  and  conferences. 

became  popular  in  response  to  less  formal  ideas  of  compo¬ 
nent  architecture  emanating  from  Microsoft  which  aren't  scalable  to  the  enter- 
prise  • 

44.7.2  Gang  of  Four  Pattern  Template 

|How  patterns  are  expected  to  be  expressed.) 

D-  of  patterns  in  the  software  domain  are  Erich  Gamma, 

Richard  Heim,  Raiph  Johnson  and  John  Vlissides  |GHjV95|,  otherwise  known  as  the 
Gang  of four.  They  have  developed  a  standard  template  for  defining  a  design  pat- 
tern.  This  template  was  what  we  hoped  to  populate  in  our  description  of  imple¬ 
mentations  for  the  metrics:  ^ 


44.7.2.1  Pattern  Name  (Scope,  Purpose) 


is 


The  pattern's  name  conveys  the  essence  of  the  pattern  succinctly.  A  good 
vital,  because  it  will  become  part  of  your  design  vocabulary. 


name 


44.7.2.2  Intent 


A  short  statement  that  answers  the  following  questions:  What  does  the  design 

pattern  do?  What  is  its  rationale  and  intent?  What  particular  design  issue  or  prob. 
lem  does  it  address? 

^Aiso  Known  As 

Other  well-known  names  for  the  pattern,  if  any. 

44.7.2.3  Motivation 


A  scenario  that  illustrates  a  design  problem  and  how  the  class  and  object  struc¬ 
tures  in  the  pattern  solve  the  problem.  The  scenario  will  help  you  understand  the 
more  abstract  description  of  the  pattern  that  follows. 


44.7.2.4  Applicability 

^What  are  the  situations  in  which  the  design  pattern  can  be  applied?  What  are 

examples  of  poor  designs  that  the  pattern  can  address?  How  can  you  recognize 
these  situations? 

^An  applicable  situation 


Fftruary  15,  195^7 


387 


Part  4,  Tool  Strategy 


44.7.2.5  Structure:  Participants 

The  classes  and/or  objects  participating  in  the  design  pattern  and  their  respon¬ 
sibilities. 

44.7.2.6  Structure:  Participant  Name 
Responsibility  for  what 

44.7.2.7  Structure:  Collaborations 

How  the  participants  collaborate  to  carry  out  their  responsibilities. 
(Collaborationj 

44.7.2.8  Structure:  Consequences 

How  does  the  pattern  support  its  objectives?  What  are  the  trade-offs  and  results 
of  using  the  pattern?  What  aspect  of  system  structure  does  it  let  you  vary  indepen¬ 
dently? 

44.7.2.9  1.  A  consequence  bullet.  Description  of  consequence 
^Implementation 

What  pitfalls,  hints,  or  techniques  should  you  be  aware  of  when  implementing 
the  pattern?  Are  there  language-specific  issues? 

44.7.2.10  1.  An  implementation  Bullet.  Description  of  Bullet 
^Sample  Code  and  Usage 

Code  fragments  that  illustrate  how  you  might  implement  the  pattern  in  C+  +  or 
Smalltalk. 

^Program  Listing 
Known  Uses 

Examples  of  the  pattern  found  in  real  systems.  We  include  at  least  two  examples 
from  different  domains, 
i  Related  Patterns 

What  design  patterns  are  closely  related  to  this  one?  What  are  the  important  dif¬ 
ferences?  With  which  other  patterns  should  this  one  be  used? 

^  Owner 

Your  Name  (yourname@host.domain).  Last  updated  on  Today's  Date 
^44.7,3  Why  We  Passed 

(We  decided  it  wasn't  appropriate.) 
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our  results  in  this  way;  it  would  have  contin¬ 
ued  the  philosophy  of  the  rest  of  the  work:  to  do  it  right.  It  would  have  continued 
m  the  vein  of  taking  the  most  rigorous  approach  that  supports  users. 

Our  problem  was  that  the  pattern  definition  depends  on  a  single,  unambiguous 
definition  of  the  use  that  is  being  addressed.  We  know  that  the  metrics  support 
agility,  a  concept  that  is  context  dependent.  So  not  only  do  we  have  a  variety  of 
users,  we  have  the  awkward  situation  of  the  problem  itself  being  dynamic. 

Current  patterns  assume  a  static  context.  Dylan,  a  new  object  oriented  lan¬ 
guage,  was  designed  with  the  Intent  of  being  able  to  move  object  approaches  into 
the  dynamic  environment.  The  project  worked  to  raise  the  issue  to  the  pattern  and 
language  communities,  and  a  notions  of  metapattem,  dynamic  pattern,  and  func¬ 
tional  pattern  have  been  proposed.  .  /u/«- 

But  progress  has  been  slow  and  fraught  with  problems.  Results  did  not  emerge 

in  time  for  us  to  use.  So  we  have  carried  this  work  forward  into  the  followon  tool 
strategy. 
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